Transcript: DjangoCon Europe 2024

Hallo, liebe Hörerinnen und Hörer. Willkommen beim Python-Podcast, Episode 57.

Heute reden wir über die DjangoCon. Hallo, Jochen.

Hallo, Dominik. Und hallo.

Und hallo, Ronny.

Ronny.

Hi. Schön, dass du wieder da bist.

Ja, wunderbar.

Freue mich auch.

Dann fangen wir vielleicht mit ein bisschen News an und dann schlagen wir direkt ein, was denn da so kommt.

Jo, ich mache hier meine Kapitelmarke für News.

Okay, Kapitelmarke hat nicht funktioniert. Ah, toll. Nichts funktioniert hier?

Das ist ja nichts Neues.

Ja.

Also, es sind keine News.

Wann war die News angekommen? Fangen wir erst mal damit an.

Ah ja, ja.

Die war Anfang Juni in Vigo in Spanien, Nordspanien, Galicien. Eine sehr schöne Stadt. Ohne jetzt tatsächlich große Highlights, aber mir hat es trotzdem gut gefallen.

Es ist ein sehr schöner Nationalpark, ein Inselnationalpark direkt vor der Küste. Wäre mal die Gelegenheit, da hinzufahren.

Das sollte man nicht verpassen.

Zeit, wandern zu gehen.

Ist das so quasi da irgendwo diese Santiago de Compostela?

Ja, genau. Das ist so ein bisschen südwestlich davon. Also genau nördlich von Portugal.

Ah ja.

Und genau, ich hatte einen Tag Zeit, wandern zu gehen. Auf der Isla Cies, glaube ich. Und das ist wirklich sehr zu empfehlen.

Klingt sehr gut.

Ja.

Ja, nächste Woche ist Europython. Vielleicht das News.

Ich weiß nicht, ob man das noch hört. Wenn ihr darüber hört, vielleicht ist es dann schon vorbei.

Ja, wahrscheinlich.

Ja.

Wir möchten gerne ein paar Themen von der DangoCon hören. Und es gibt aber noch ein, zwei andere News.

Ja, genau.

Wir haben jetzt schon einige Zeit keine Sendung mehr.

Ja, der Termin ist direkt. Dann ist das immer dasselbe Problem im Moment. Aber gut.

Also, ein News ist ganz interessant. Google ist ja so ein bisschen unter Druck in letzter Zeit.

Man sieht sie halt öffentlich schwitzen. Dieses ganze AI-Thema, das ist irgendwie, ja.

Können sie nicht so richtig entscheiden? Steigen sie jetzt voll ein oder doch nicht? Was machen sie? Oh nein.

Ja, und jetzt haben sie sich für etwas anderes entschieden, nämlich ihr Patentime-Team zu feuern.

Die haben dabei, glaube ich, direkt wieder ein neues eingestellt.

Ich glaube, in Deutschland sogar.

Ja, sie wollen jetzt, sie sind jetzt, was, alles zu teuer mit dem, mit den teuren...

Die Amerikaner wollten alle 300.000 Dollar haben pro Jahr. Haben sich irgendwann gedacht, das können wir in Deutschland auch für die Hälfte haben.

Genau, dann gehen wir halt in so ein Billiglohnland und dann in so eine, so eine, irgendwie, keine Ahnung, Billigvorstadt.

Und zwar gehen sie nach München und wollen da ein neues Team aufbauen.

Da sind sie ja auch schon, da sind sie ja auch schon ein bisschen weiter gewachsen.

Aber ich bin mal gespannt, ob das klappt. Ob sie da jetzt irgendwie, keine Ahnung, äquivalent rekrutieren können. Mal sehen.

Aber ja.

Die haben bestimmt erkannt, wo die guten Peißenleute sitzen.

Und wenn man in München guckt, die sind ja eh immer ganz oben, wenn man sie fragt.

Entschuldigung, ich wollte jetzt keinen Lokalpatriotismus hier auffangen.

Ja.

Genau, also das ist, das ist schon mal irgendwie, war irgendwie, aber normalerweise ist das ja nie passiert.

Das ist ja immer so, irgendwie mehr Peitenleute einstellen und so, voll gut.

Und jetzt, und welche, hat man das irgendwie so abgerückt, rückgebaut? Das ist neu.

Vielleicht ist aber jetzt einfach nur so eine normale Glättung, die irgendwann mal ist, oder?

Ja, kann auch sein, ja.

Also vielleicht ist auch, muss man da nicht so viel reininterpretieren.

Das ist schon richtig.

Es gibt tatsächlich von Peiten 3.13 jetzt so erste Beta-Versionen.

Ja.

Das heißt, wenn man mal ausprobieren will, ob das eigene Zeugs, was man so baut, irgendwie damit tut,

dann kann man das jetzt mal machen und, tut eigentlich, ne?

Ja, es gibt, glaube ich, jetzt auch, wo war das, irgendwas kann jetzt auch, man kann jetzt auch Wheels bauen für 3.13.

Ich habe heute echt keine Zeit gehabt, mich die News nochmal anzugucken.

Insofern tut mir leid, wird etwas durcheinander, aber, ja.

Da müssen wir auch mal durch.

3.13 kann man auf jeden Fall jetzt mal so, jetzt ist der richtige Zeitpunkt, um das mal auszuprobieren.

Was habe ich denn noch?

Oh, ich habe gesehen, es gibt, ich weiß aber nicht, ob das News ist, aber es gibt ein Software-Development-Kit für One Password.

Also ich bin immer noch nicht, ich bin immer noch bei One Password.

Mir tut das zwar etwas weh, dass das alles super teuer ist und so, aber ich finde es immer noch so der beste Password-Manager.

Und der hat jetzt auch einen Python-API im Software-Development-Kit gekriegt.

Das heißt, man kann von Python aus irgendwie One Password anfragen.

Also sozusagen, man kann halt Python-Sachen schreiben und dann fragt das Ding halt One Password.

Und dann sagt das Ding halt, ja, guck hier mal in die Kamera oder hier, leg mal da deinen Finger drauf.

Und dann kann man sich authentifizieren, was ja für manche Sachen ganz nett ist.

Wie teuer ist denn das? Weißt du das?

Wenn wir Werbung machen, eigentlich hätten wir nicht beides Episoden-Sponsorien.

Also One Password kostet, das ist wirklich, die haben ja auch wahnsinnig viel Fremdkapital aufgenommen.

Und das kostet pro User irgendwie sowas 35 Dollar oder Euro im Jahr ungefähr.

Und das ist halt schon...

Und gab es Debatten, wie lange ist der letzte Breach her?

Ja, es gab einen auch über Okta, der war aber nicht so furchtbar schlimm.

Also ist auch so ein halbes Jahr her, glaube ich, oder so.

Ja, ich wollte gerade sagen, ich habe irgendwas im Kopf hier.

Genau, was haben wir noch?

Ach so, ja, es gibt auch gute Nachrichten.

Also das ist ja auch so ein Ding, da kriege ich immer Angst, wenn ich mir angucke, wie das so funktioniert.

PyPI macht wahnsinnig viel Traffic.

Also was darüber geht, ist halt atemberaubend und es kostet auch wahnsinnig viel Geld.

Und das funktioniert halt darüber, dass es einen CDN, so Content Delivery Network Anbieter gibt, der sponsert das halt, der hostet PyPI.

Und ich weiß nicht, was man zahlen müsste, wenn man das nicht irgendwie kostenlos kriegen würde.

Es wäre sehr viel und das wäre ein Riesenproblem, weil, ja, per Pippe installieren würde dann halt nicht mehr funktionieren.

Und die haben jetzt gerade auf der Python, PyCon US verkündet, dass sie...

... für fünf weitere Jahre PyPI sponsern wollen.

Cool, cool.

Das ist natürlich praktisch.

Also es gibt Py ist noch mindestens fünf Jahre.

Ja, genau.

Dann tatsächlich jetzt im Juni vor gar nicht, ja, vor zwei, drei Wochen ist NumPy 2.0 erschienen.

Nach irgendwie, ich weiß nicht, 14 Jahren Entwicklungszeit oder so.

Das war eine ganze Zeit lang in Progress.

Und, ähm...

Genau.

Ist vielleicht jetzt nicht der günstigste Moment, um zu steigen, sondern man sollte vielleicht das jetzt mal auf kleiner zwei pinnen oder so.

Und dann mal gucken, bis alle anderen irgendwie sich angepasst haben, weil das bricht halt einige, äh, einige Geschichten.

Aber, ja, schön, dass es jetzt raus ist und dann, äh, es macht einige, ich, äh, wie gesagt, ich hab keine, keine Ahnung, was alles genau passiert ist.

Oder ich wusste es mal, hab's wieder vergessen.

Ähm, ja, Performance ist irgendwie besser geworden.

Es sind auch ein paar Upchains drin, das heißt, wir müssen ein bisschen aufpassen.

Ja, genau.

Weil, wenn ihr da irgendwie einfach updatet, dann kann es sein, dass euch irgendwie relativ viele Dinge kaputt gehen.

Also, ich hab so ein paar Updates gehabt, da war es so ein bisschen hässlich, weil ich tatsächlich downgraden musste, weil da irgendwie Pakete irgendwo ganz tief drin waren, die dann leider nicht mehr wollten und die man halt umbauen hätte müssen oder sowas, wo man dann erstmal verstehen muss, was alles ist.

Das dauert alles relativ viel Zeit.

Nicht so schön, aber waren ein paar Upper Boundaries dann in den Projekten auf einmal drin.

Ja.

Aber gut, also, das ist eigentlich super.

Das ist auch eh ein Semantic-Version-Ding.

2.0, Breaking Up, Changes.

Ja, ja, genau.

Genau, dann gibt's eine neue, also eine erste 1.0-Release von Polars, was ja auch vielleicht ganz, ganz nett ist, dass man sich jetzt halt so darauf verlassen kann, dass die API da mal eine Zeit lang stabil bleibt und so.

Und da ist auch sonst nichts Großartiges dazugekommen.

Nutzt du das irgendwo viel oder ein bisschen?

Nee, viel nutze ich das nicht.

Ich nutze das ab und zu mal, aber...

Ja, Pandas, weil ich mich halt da so an Pandas gewöhnt habe.

Ja, aber nur, weil du dich dran gewöhnt hast.

Ja.

Aber bei Pandas haben die auch ein bisschen schneller gemacht.

Ich weiß gar nicht, gibt's irgendwie wirklich jemand, der das mal getestet hat, was so für was besser geht?

Ja, also Polars ist tatsächlich, wenn man einfache Sachen macht, ist es halt ein gutes Stückchen schneller.

Es gibt halt Dinge, die gehen mit Polars gar nicht so und die gehen mit Pandas und dann...

Und ich meine, ich hab mich an diese, also viele Sachen sind halt auch total komisch und ich hab mich halt dran gewöhnt, zum Beispiel an diese Multi-Index-Geschichten und so.

Wahrscheinlich ist es keine gute Idee und das ist richtig...

Ja, das ist richtig, dass Polars das alles nicht gemacht hat und auch selbst die Leute, die Pandas gebaut haben, also das weiß man, McKinney sagt heute im Podcast so, ja, das mit diesen ganzen komplizierten Index-Geschichten und so, das war wahrscheinlich alles nicht so richtig.

Aber, ja, wenn man sich mal dran gewöhnt hat, dann ist das halt klar, wie man das damit macht und alles andere muss man halt dann denken.

Ja, deswegen benutze ich halt eigentlich immer noch lieber Pandas, aber, ja, ich glaube, Polars ist schon der richtige Weg eigentlich.

Ja.

Genau.

Genau, was gibt's noch? Psycho-PG, 3-2 ist raus, also auch etwas, ich weiß nicht, ob alle schon umgestiegen sind auf 3, also ich hab das wahrscheinlich...

Ja, also es gab ja Psycho-PG 2 explizit und wenn man jetzt aber normal Psycho-PG nimmt, dann ist das jetzt normal 3.

Ja, genau, klar. Ja. Und, ja, super, da ist halt auch so Essing-Support jetzt mit drin und diverse Geschichten. Also...

Auf Postgres 15, was ist das Minimum für Psycho-PG?

Oh, das...

Warte mal, lass mal grad gucken.

Bestimmt auch bei Tifa.

Na, wahrscheinlich, wahrscheinlich, ich würde jetzt tippen Postgres 12 oder so.

Minimum steht da nicht.

Nee, steht, steht, ich weiß es, ich weiß es.

Keine Low-Hanging Fruit, okay, auch nicht so wichtig. Die meisten Leute, sind die bei alten Datenbanken oder bei neuen, was meint ihr?

Ich denke alte Datenbanken, weil die meisten halt nicht die Kontrolle haben über die Distributionen, auf denen ihr Zeugs läuft und dann haben sie halt irgendwie entweder alte Datenbanken, weil Datenbanken auch oft nicht...

Kontrollerisiert sind, ne?

Mhm.

Und, oder sie haben es kontrollerisiert und haben dann vergessen, dass irgendwie, also, aber ich sehe in der Praxis, sehe ich ganz oft alte Datenbanken.

Ja, ja, stimmt.

Und ich, ehrlich gesagt, ich finde es komisch, weil das ist halt so, ich meine, es kostet eigentlich ja nicht viel, das abzudaten oder da abzudaten zu bleiben und es bringt halt ordentlich was, also, wenn ich jetzt mir angucke, so Postgres 12 oder so, was ich häufig sehe oder...

Also bis, also bis, wenn man jetzt stattdessen ein Postgres 16 nimmt, dann ist es halt schon, da hat sich schon einiges getan, also, da kriegt man irgendwie so 30% Performance-Proofment einfach so gerade.

Einfach umsonst, ja.

Ja, also, ja.

Genau, ähm, ja, äh, dann, oh, hm, HTMLX 2.0 ist erschienen.

Aha.

Auch ganz interessant, da hat sich auch nichts geändert, sondern das ist, äh, einfach nur hochgezählt, äh, und gut, ist ein paar Sachen entfernt worden, also ein paar Extensions, die WebSockets-Extension ist nicht mehr da.

Ja.

Nicht mehr drin, oder ein paar Dinger, äh, genau, ja, und...

Du benutzt das immer noch so gern?

Ich benutze das immer noch super gern.

Ich auch.

Ja, ich habe es auch jetzt letztens wieder in einem, äh, in einem Projekt, äh, gehabt und das ist, äh, ja, es war echt total super, ich habe damit irgendwie eine Menge...

Wie würdest du denn einen Chat umsetzen?

Äh, ja, gut, okay, Chat, da muss man dann drüber nachdenken, vielleicht ist es da besser, dann was anderes zu nehmen.

Ja.

Könnte schon sein.

Ich meine, man kann es bauen, aber...

Ja, ist ja manchmal vielleicht der Echtzeit dann tatsächlich, wenn der Echtzeit eine Reaktion hat, irgendwie interessant, wenn man jetzt pollen würde, dann hast du immer so ein bisschen Latenz.

Server-Send-Events, glaube ich, geht damit?

Ja, das geht damit natürlich auch, aber das ist ja dann fast das Gleiche, also es ist auf jeden Fall ähnlich wie WebSockets auch, also es ist halt nicht bidirektional, aber du hast halt auch die ganze Zeit eine stehende Verbindung, die halt die ganzen anderen komischen Schwierigkeiten hat, die man dann halt so hat, wie, ja, wie loadbalancen wir das jetzt denn eigentlich, was ist denn, wenn ich jetzt irgendwie...

Deployment mache und ich restarte das Ding, was passiert denn da mit der Verbindung?

Ist jetzt erstmal weg.

Kommt sie wieder?

Kommt sie nicht wieder?

Der Mensch am anderen Ende des Chats merkt ja einfach nach drei Tagen irgendwie, dass keiner mit ihm redet und denkt alle, er stinkt irgendwie und niemand will mit ihm reden, tatsächlich ist einfach nur diese Verbindung weg.

Ja, also da kommt man in all diese blöden Fehlerfälle rein und das ist halt bei WebSockets und bei Server-Send-Events so.

Insofern, ich weiß nicht.

Also wenn man es irgendwie ohne sowas machen kann, würde ich es ohne sowas machen, aber kann sein, dass Chat eine der wenigen Sachen ist, wo man das halt tatsächlich braucht.

Ja.

Und was ist mit Chat mit dem Server?

Chat mit dem Server ist...

Also keine Ahnung, du schickst dem Server eine Frage und nicht einem anderen Menschen.

Nee, da brauchst du es nicht.

Achso, du meinst jetzt sowas wie Chat-GPT, wenn man das implementieren wollte.

Genau, da brauchst du es nicht.

Das geht, Request-Response, super.

Dann wartest du einfach drauf.

Ja, also du kannst halt dann...

Du kannst ja auch das anzeigen, was dann zurückkommt direkt.

Aber da brauchst du keine stehende Verbindung.

So gejankt jetzt, oder?

Ja, du kannst einfach, sobald da was kommt, kannst du ja das anzeigen.

Das geht.

Genau.

Genau, das ist auch sowas.

Genau, dafür braucht man keine direktionale Verbindung oder keine stehende Verbindung.

Okay, dann 5.

5, 1.

5, 1, Alpha erschienen, genau.

Ich weiß nicht, ob hier irgendjemand genau die Liste der Neuigkeiten und so da mit dabei hat.

Also ich meine, es dauert auch noch ein Momentchen, bis das erscheint, aber...

Ist das die erste Alpha?

Ja.

Also was ich hier schon sehe...

Ah, Query-String, super.

Das habe ich hier halt schon ein paar Mal selber gebaut.

Aber warum gibt es das denn nicht?

Genau, man hat...

Also das Problem ist, wenn man quasi ein paar Dinge hinzufügen will, dann...

Query-String zum Beispiel, wenn man irgendeinen Filter angeschaltet hat oder so, dann ist halt die Frage, okay, aber da sind ja jetzt möglicherweise schon Sachen gesetzt und dann muss man das irgendwie...

Ja, wie updatet man das denn?

Und da gibt es jetzt ein Template-Tag für, wo man halt einfach den Query-String kriegt.

Und das ist natürlich praktisch.

Genau.

Ich hatte das Gefühl, dass da viel Quality-of-Life-Sachen dabei sind.

Jetzt nicht die großen Game-Changer, die sind jetzt eher dann für 5.2, glaube ich, geplant.

Später mehr.

Ja.

Ja, sondern eher Kleinigkeiten, die einem einfach helfen.

Besser.

Und angenehmer zu arbeiten.

Ja.

Oh, es gibt Connection-Pool-Support für Postgres, was dann auch praktisch ist.

Also ich meine, ehrlich gesagt, für meine Sachen ist es nicht so...

Also da komme ich sowieso nie so an die Grenzen, dass ich da wirklich ein Pool lieber hätte oder so, sondern es ist alles egal.

Aber wenn man das Problem hat, dann ist es natürlich doof, wenn man da irgendwie was anderes tun muss.

Ja.

Ja, ja, ja, ja, ja.

Keine Ahnung, was das ist.

Aber ich würde sagen, über die ganzen Neuigkeiten bei Dango, da können wir doch tatsächlich den Ronny gleich besser fragen, weil der von der Dango-Con wahrscheinlich mehr erzählen kann als der 5.1.

Ich glaube, das ist so wahnsinnig...

Ja, genau.

Ist auch nichts Weltbewegendes mehr.

Alles klar, dann, genau.

Haben wir nur ein Event, dass es das gibt und...

Dann sind wir vielleicht mit den News heute schon ein bisschen durch oder habt ihr noch irgendwas, was ganz total relevant wichtig war?

Nicht von meiner Seite.

Okay.

Gut.

Dann erzähl doch mal von der Dango-Con, lieber Ronny.

Danke, Ronny.

Also, ich hab...

Also, erstmal, du...

Eigentlich müsstest du ja von dir selber erzählen, weil du hast ja auch was gesagt, glaube ich sogar, ne?

Genau.

Und was Cooles erzählt.

Und vielleicht fangen wir doch einfach damit an, dann können wir danach so von allgemeinen Sachen erzählen.

Ja, genau.

Also, wie gesagt, ich heiße Ronny.

Ich arbeite seit 2012 mit Dango.

Ich hab damals mit 1.4 angefangen, was lange, lange her ist.

Damals hatten wir auch noch ein anderes Versionsschema, also das ist länger her, als es klingt.

Ich bin jetzt seit vielen Jahren Tech-Evangelist in meiner Firma.

Ich arbeite bei der Agentur Ambient in Köln und hab da durch die Möglichkeit, mich mit der Thematik zu beschäftigen und mich in dem ganzen Django-Backend-Kontext so ein bisschen auch up-to-date zu halten und da auch Sachen zu machen.

Zum Beispiel auch mal zu einer Konferenz zu fahren und einen Vortrag zu halten.

Das habe ich dieses Mal das erste Mal gemacht.

Das ist das erste Mal auf einer echten Konferenz.

Ich war, man könnte vielleicht sagen, zum Warmlaufen letztes Jahr bei dem Django-Day in Kopenhagen.

Das war sehr cool.

Das ist so eine Mini-Konferenz.

Das ist so ein Raum für so 60 bis 70 Leute, würde ich sagen.

Und das ist nur ein Tag.

Und das war sehr nett, sehr familiär.

Und das war so das erste Mal, dass ich irgendwie vor, naja, literally laufender Kamera das gemacht habe.

Das stimmt überhaupt nicht.

Wir haben dich schon ganz oft live was erzählen hören.

Ja, aber das war nicht mit Livestream zu.

Das ganze Internet konnte zu gucken bei euren Livestreams bei Ambient.

Während der ganzen Zeit, in der letzten Zeit, ja.

Ja, die Django-Meetups machen wir nicht.

Ach so, das meinst du.

Ja, okay.

Ja, doch.

Genau, ich bin nämlich beim Django-Meetup Köln.

Ich organisiere das und da halte ich auch gelegentlich meinen Vortrag.

Längst nicht mehr so oft wie früher, was, glaube ich, ein gutes Zeichen ist.

Das heißt, das Meetup funktioniert, wenn sich Leute finden, die da Spaß daran haben, was vorzutragen.

Genau, und da habe ich einen Vortrag gehalten über mein Package, das ich für Django gemacht habe.

Das nennt sich Django Pony Express.

Böse ist im Endeffekt das Problem, wer schon mal mit Django, also wir machen meistens, so von meinem Job her,

machen meistens Business-Applikationen und meistens baut man da relativ viele E-Mails.

Und E-Mails mit Django zu bauen, das geht alles, das funktioniert auch technisch alles sauber,

nur die, ich mag diesen Begriff sehr, die Developer Experience ist nicht so richtig gut,

weil man da relativ viel Low-Level-Sachen machen muss, vor allem, wenn man jetzt nicht nur irgendeine E-Mail rausschicken möchte,

sondern halt eine, die modernen Business-Ansprüchen genügt, also sprich eine HTML-E-Mail, die in 50 Sekunden,

die entsprechende Heller gesetzt hat, die einen Unsubscribe-Link hat, die irgendwie ansprechend aussieht, etc.

Und da habe ich mir was überlegt, dass wer Django kennt, kennt ja wahrscheinlich auch Class-Based-Views

und ich habe das ganze Thema Class-Based-E-Mails genannt.

Und diese Class-Based-E-Mails habe ich mich sehr an den Class-Based-Views orientiert,

um einfach mal eine Lösung zu bauen, wo es halt angenehmer ist, dass halt, wenn ich halt eine E-Mail habe,

die halt dann HTML-Templates hat oder Inhalt hat, einen Plain-Text-Part-Inhalt,

Übersetzungen, bestimmte Header, bestimmte Variablen, die für das Base-Tempel benötigt werden,

dass ich da halt nicht jedes Mal so riesige Funktionen hin und her kopiere,

sondern im Endeffekt halt wirklich nur drei oder vier Zeile habe

und die restlichen Sachen halt an einer sinnvollen Stelle gekapselt sind.

Und ein zweites großes Problem, was mich halt auch persönlich immer sehr gestört hat, ist,

dass E-Mails, weil die ja irgendwie so ein bisschen eine externe API sind,

weil das halt, ne, man schickt die irgendwie raus und die kommen dann quasi vielleicht wieder bei mir an,

wenn ich es mir selber schicke, dass wir die nicht so richtig getestet haben,

weil es einfach auch mühsam ist.

Und das Django-Test-Framework bringt einem da so ein paar Tools mit,

aber die sind alle so ein bisschen versteckt.

Und da habe ich dann so einen Wrapper gebaut, der auch so ein bisschen,

dass man diese E-Mail-Outbox, wenn man E-Mails in einem Test verschickt,

dann landen die in so einer Liste, in einer Outbox, werden die gesammelt,

dass sie nicht aus Versehen rausgeschickt werden an irgendwen,

und dass man auf diese Liste so ein bisschen wie in einem Query-Set zugreifen kann,

dass man kann nach Subject, nach Inhalt filtern, man kann gewisse Assertions machen,

ob zum Beispiel in beiden Content-Parts, es gibt ja mehr als nur HTML und Plain-Text,

ob in den Context-Parts da bestimmte Dinge drin sind und so weiter.

Und da habe ich einen Vortrag drüber gehalten, das hat sehr viel Spaß gemacht,

ich war sehr nervös.

Ich wollte gerade sagen, warst du aufgeregt?

Ich war sehr aufgeregt, aber es hat sehr viel Spaß gemacht tatsächlich.

Ich war unendlich viel schneller als bei den Malen, wo ich geübt habe.

Das ist glaube ich so eine Sache, das ist man immer, aber ich war wirklich schnell.

Ich glaube, ich habe auf 21 Minuten Testzeit 16 Minuten Vortragszeit gehabt.

Ach, du hast immer so schnell geredet wie ich.

Ich weiß es nicht.

Ich habe versucht, extra ein bisschen Zeit zu lassen, aber ja, hat so mittelgut funktioniert.

Nichtsdestotrotz auch viel positives Feedback bekommen

und ist auch tatsächlich nochmal eine ganz andere Art, auf so einer Konferenz zu sein.

Das war jetzt, glaube ich, meine fünfte oder sechste DjangoCon mit ein paar,

ich glaube fünfte, mit zwei Remote wegen Corona.

Und das ist echt nochmal ein ganz anderes Gefühl.

Also ich finde generell kann ich das jedem nur ans Herz legen,

wer es noch nicht gemacht hat, geht mal auf eine Konferenz.

Auf meiner allerersten DjangoCon.

Dachte, habe ich halt Uni-Style erwartet.

Da steht irgendwer und erzählt was langweiliges und dachte, ich gehe eigentlich wegen den Leuten dahin.

Tatsächlich gehe ich auch gerne wegen den Leuten dahin, jetzt wo ich auch viele kenne.

Aber die Vorträge sind auch wirklich gut.

Und wenn man denkt, dass das halt auch alles auf einem kleinen Budget läuft,

da jetzt keine große Tech-Company dahinter steht, die da irgendwie Millionen einfach mal so verschenkt,

sondern das alles irgendwie von Volunteers getragen wird und dann die sich freuen,

wenn halt irgendeine Firma irgendwie ein Tausi reinwirft, ist das schon echt beeindruckend.

Und genau, da waren echt coole Sachen dabei.

Das, glaube ich, der große Game-Changer sind die Background-Workers.

Das ist eine von diesen DEP, also so eine Django, ich weiß gar nicht, was die Abkürzung bedeutet.

Django Enhancement Proposal.

Ah ja, genau.

Dieses DEP, ich glaube 14 oder sowas.

Die sind auch irgendwie letzte Zeit erst wieder entdeckt worden.

Ich glaube, dass es die gibt und die werden jetzt auch wieder recht populär.

Ich glaube auch mit den neuen Fellows, Sarah und Natalia.

Und diese Background-Workers sind im Endeffekt eine Idee,

dass man, wenn man in einem Django-Projekt Asynchrone...

Ich glaube, da müssen wir gleich noch ein bisschen genauer drauf eingehen,

vielleicht so als extra Thema, weil da haben wir vielleicht noch ein, zwei coole Links zu.

Deswegen erzähl gerne noch ein bisschen mehr zu deinem Talk über E-Mails,

bevor wir auf die Background-Tasche gehen.

Okay.

Ja, genau.

Also die, ja, was habe ich denn, was kann ich dazu noch sagen?

Irgendwie, war das nicht auch irgendwas, wo so ein Architektur-Design,

dann irgendwie so ein bisschen eine Rolle spielte oder,

ne, vielleicht habe ich das auch einfach falsch.

Einfach nur objektorientierte E-Mails quasi.

Genau, und es ist halt, es ist halt einfach ein Wrapper um die relativ low-levelige API,

wenn man halt, wie gesagt, ein bisschen aufwendigere E-Mails bauen möchte.

Ja, das macht Sendmail mit ein bisschen Fluff.

Genau.

Ja, genau.

Weil Sendmail selbst, das erstellt ein Python-E-Mail-Objekt, glaube ich.

Das gibt doch gerade eine große Diskussion, weil bei Python, das scheinbar etwas deprecated

wurde, in einer letzten Version.

Und Django noch auf den alten Sachen, ich glaube tatsächlich deprecated, aber da gibt

es noch etwas Neueres, Cooleres und die Django-Sachen unter der Haube benutzen noch die alten und

dann ist gerade viel in Bewegung bezüglich E-Mails, interessanterweise.

Ich bin da ganz aus Versehen auf diesen Zug aufgesprungen.

Direkt eine blöde, andere Frage, wie verschickt ihr denn E-Mails?

Also tatsächlich, das ist auch eine Frage, die ich jedes Mal gestellt werde, wenn ich

diesen Vortrag, ich muss gestehen, ich habe den eigentlich nicht.

An mehreren Occasions recycelt.

Das ist eine Frage, die sehr oft kommt.

Bei mir geht es wirklich im Endeffekt nur um die Developer Experience und um die Maintainability.

Also sprich, wie erstelle ich programmatisch diese E-Mail, wie stelle ich sicher, dass da

alles drin ist und wie kann ich das nachher testen?

Alles, was danach kommt, also im Endeffekt, das ist alles nicht das, wo das Package ansieht.

Also da hört es quasi auf.

Also bei den Unit-Tests, je nachdem, wie man es definiert, ist quasi dann das Ende und

danach.

Kann man halt dann die E-Mail so verschicken, wie man sie halt mit Django sonst verschicken

möchte.

Also ob man da jetzt irgendeinen Mail-Hawk reinhängt oder irgendein super abgefahrenes

E-Mailing-Cluster hat oder seine eigene Gmail-Adresse dafür nutzt oder einfach das bei SES reinwirft.

Das ist nichts, was man im Package versucht zu lösen.

Wie macht ihr das?

Wir selbst nutzen SES.

Das ist von Amazon.

Ich glaube, das gibt es aber auch in, also ich glaube, das ist ein Standard sogar.

Ich bin nicht ganz sicher.

Ich glaube, Amazon hat ja viele von diesen Standards definiert und das ist ein Service,

der ist halt sehr günstig und sehr leistungsfähig.

Ich habe für ein Privatprojekt, ich engagiere mich da für Kinder in Bolivien, haben wir

früher unseren Spendern und Interessenten so einen Jahresbericht per PDF geschickt, das

damals noch, bevor wir HTML-E-Mails hatten und diese PDFs, das war dann immer so mit

den Bildern, auch wenn man die runtergerechnet hat, war immer so 500, 800 Kilo bei, das ist

schon relativ groß für eine E-Mail und unsere alten Mail-Server sind regelmäßig, da ist

irgendwie abgekackt, hängen geblieben, mühsam.

Dann habe ich irgendwann auf SES umgestellt.

Alle E-Mails zu versenden kostet dann vielleicht ein Euro oder zwei, ich weiß es nicht genau

und das läuft halt einfach.

Also du kannst dir eine beliebige Menge von E-Mails geben und die kommen halt an.

Das ist halt sehr, sehr angenehm.

Genau.

Ja und tatsächlich eine Sache kann ich dazu sagen, was mich auch sehr gefreut hat.

Ich habe ja wie gesagt für den Vortrag auf der Con gutes Feedback bekommen, habe mich

dann mit ein paar Leuten unterhalten und habe ja noch ein paar Tipps bekommen, weil ich

halt in der Conclusion auch überlegt habe, was da Sachen drin sind, die meiner Meinung

nach auch gut ins Django Core, also in das Framework passen würden und dass wir dort,

dass ich mich freuen würde halt was zu contributen, aber ich habe bis jetzt halt noch nicht so

die richtigen Sachen hatte, es hat nie richtig funktioniert, habe ich ein paar Tipps bekommen,

wie ich das mache.

Es gibt nämlich ein Django Forum, das wird es auch gerade noch ein bisschen, die versuchen

gerade so ein bisschen die Kommunikation da auch drin zu zentralisieren und da dann einfach

meine Idee, also mit etwas kleinem Anfang.

fangen, zum Beispiel dieser Testing-Helper,

dass man halt quasi

durch einen, also

dass man alle textbasierten

Medieninhalte einer E-Mail, also

in den meisten Fällen HTML und Plaintext,

wirklich einfach gucken kann, ist

dieser String da drin, also zum Beispiel

weiß ich nicht, ist, da steht da drin

lieber Jochen als Anrede oder steht da

drin Auftragsbestätigung oder ist da diese

Auftragsnummer drin, solche Geschichten.

Und diesen Helper haben wir

dann in einem Forum-Thread ausdiskutiert.

Die Lösung, da haben sich auch sehr viele Leute beteiligt,

die Lösung, die rausgekommen ist, ist viel besser als das, was ich mir

alleine überlegt hatte. Es war viel

weniger zu implementieren, lustigerweise auch,

was man alleine gemacht hat.

Es gibt diesen schönen Spruch,

Weeks of Programming can save hours of

Planning, das war wieder sehr wahr.

Und genau, dann

ist vor zwei Wochen, glaube ich,

dann das auch gemerged

worden in Django Core, also in 5.2

habe ich meinen ersten Commit, was mich sehr freut,

jetzt nach zwölf Jahren.

Cool. Vielen Dank.

Genau.

Ja, das klingt cool.

Also, ja, ich muss es eigentlich auch mal ausprobieren.

Ich hatte das zwischendurch mal so angeguckt, aber nicht dann angefasst,

weil die E-Mail-Lösung bei mir war schon

fertig und ich hätte hier alles umbauen müssen.

Ja, ich kenne das.

Aber eigentlich, für das Template wäre es eigentlich cool,

das drin zu haben, weil das klingt danach, als müsste man

das an verschiedenen Stellen schön benutzen können.

Weil halt auch, wie du sagst, diese ganzen

Features, Templates per

HTML und so weiter, sehr gerne

genutzt werden. Also, tatsächlich ein Feature,

was ich persönlich sehr mag,

einfach so ein Convenience-Feature,

der Faktor interessiert

die wenigsten Leute wirklich der Plain-Text-Part,

weil die normalen, die modernen E-Mail-Clients

oder die Web-basierten Clients, den

eh nicht anzeigen. Das heißt, die einzigen

Arten, wo man das sieht, ist, wenn man

so ein E-Mail-Client hat, dann geht so ein Pop-Up auf,

das nimmt meistens den Plain-Text-Part.

Oder wenn halt irgendjemand auf seinem

Linux-1980-Konsolen-basierten

E-Mail-Programm noch

sitzt. Da gibt es auch so ein paar Spezies, die das

machen. Aber ansonsten sieht das halt niemand.

Und ich habe mir mit einem externen

Package als Default

rendert der einfach das HTML-Template

als Plain-Text und tauscht dann halt die Tabellen

durch Pipes und sowas. Die Struktur ist

nicht schön, es funktioniert. Auch Links und sowas

kriegt der hin. Also das kriegt

dann quasi wieder der

Client dann hin, der

das dann auch trotzdem, auch Plain-Text

meistens zumindest, dann wieder

irgendwie interpretiert. Und das ist sehr

angenehm, weil dann hat man keine doppelten Templates mehr. Und das

ist natürlich schon ein Problem, dass man durch diese doppelten

Inhalte, wie zum Beispiel bei uns in einem Projekt, wo wir

gearbeitet haben, hatten wir bestimmt 50

verschiedene E-Mails, alles mögliche

um halt den Kunden zu informieren, was so mit

seinen Dingen passiert ist.

Und da wurde ständig vergessen, eine von

beiden Teilen anzupassen. Das kann man natürlich in gewissen

Maßen durch diesen Test-Helper

lösen, dass man das einfach unit-testet.

Nichtsdestotrotz, wenn es ein Rechtschreibfehler oder sowas ist,

hat man vielleicht darauf gerade nicht geschaut.

Das war ein ständiger Pain. Und

das kann man sehr gut damit halt einfach

erschlagen und löst

das Problem damit. Das ist sehr angenehm.

Sehr gut. Und

du hast gesagt, er macht auch sowas dann wie

Opt-Out-Links oder

für E-Mail-Newsletter oder sowas dann direkt mit drin.

Ist das da in einem Package drin, oder?

Also das Package nicht. Die Idee ist quasi,

dass man, also diese, dass man,

also ich biete quasi, also

das Package, nicht ich, nicht ich persönlich,

biete so eine

Basisklasse. Und wenn man von dieser Basisklasse

erbt, dann kann man halt dann

eine E-Mail definieren, kann ein paar Attribute setzen, zum Beispiel

das Subject setzen,

das Template setzen und halt gegebenenfalls noch Kontextvariable

mitgeben, zum Beispiel den Auftrag oder

den Link oder irgendwas, was halt der

Inhalt der E-Mail ist.

Jetzt hat man aber natürlich oft einfach

so ein, also die E-Mails, die man schickt

aus dem System, sollen ja irgendwie

einheitlich sein. Du hast, wie auch

bei einer Webseite, hättest du ein Basis-Template.

Du hast das Logo oben drin, du hast dann

vielleicht eine generelle Anrede, du hast ein Footer,

wo ein paar legale Sachen drinstehen, wo vielleicht

ein Unsubscribe-Link drin ist. Und

diese ganzen Sachen,

die ganzen Informationen, die man dafür braucht,

das sind auch die dynamischen Sachen. Zum Beispiel, wenn man

sagt, der Unsubscribe-Link enthält ein Hash oder sowas,

dass der Nutzer identifiziert werden kann,

der das draufgeklickt hat und solche Geschichten.

Und wenn man da einfach von der

meiner Pony Express Basisklasse

ableitet, eine eigene Basisklasse macht,

dort dann halt die zum Beispiel, die

GetContextData, wer Django kennt, weiß, was ich meine,

überschreibt,

dann kann man da halt einmal die ganzen Sachen definieren.

Oder zum Beispiel, dass man Subject-Prefix hat.

Ich persönlich finde, es sieht immer schön professionell aus,

wenn alle E-Mails, die vom System kommen,

halt irgendwie geprefixet sind. Oder zum Beispiel dann irgendwie

mein-webshop.de

und dann halt Account erstellt, Passwort-Reset

und was auch immer. Und diese Sachen kann man

einmal definieren und jede E-Mail, die man dann

weiter erstellt, leitet dann halt von dieser eigenen

Klasse ab. Und das,

ich meine, das ist halt ganz normale Objektorientierung,

das hat jetzt nichts mit dem Pony Express zu tun,

aber das ist halt, das macht es sehr angenehm und führt

auch dazu, dass die eigentlichen E-Mails, die mich dann

am, die ich am Schluss dann, wo ich dann auch die N,

die N-te,

implementieren muss,

dass das wirklich dann meistens halt nur

zwei oder drei Zeilen Code sind. Was es natürlich auch vieler

sehr angenehm macht, neue E-Mails

hinzuzufügen.

Genau.

Cool, cool.

Ähm, hast du da auch so White-Label-Templates

dabei, die quasi gar nichts vorgeben,

aber die es schon gibt und die man einfach benutzen kann?

Also ich tatsächlich, wenn ich das mache,

ich fange immer an mit einer Google-Suche

nach Responsive-E-Mail-Template, da lande ich

immer bei dem gleichen GitHub-Report,

das es schon seit, ich glaube, 2015 oder sowas gibt.

Das ist immer noch überraschend gut und

das funktioniert auch. Das müssen wir unbedingt

in die Show noch stellen.

Das ist super simpel,

es tut es aber irgendwie. Ich weiß

auch nicht genau warum, aber wenn man sich halt da ein paar Regeln hält,

je nachdem, wie alte E-Mail-Clients man unterstützen möchte,

ähm,

die früheren Outlook-Versionen

sind da ja ziemlich wild, die dann unter der Haube so

einen Indexbrowser 5 oder sowas haben.

Das tut dann schon weh, wenn man die unterstützen möchte.

Aber, ähm, wie gesagt, kommt halt auch immer dann

drauf an, ähm, wie wichtig das dann ist.

Also vielleicht akzeptiert, wie halt auch mit

Browsern, ne, vielleicht ist auch einfach okay, wenn dann der eine,

der halt noch den Indexbrowser 11 nutzt, wenn das dann die Webseite

halt nicht perfekt aussieht. Von daher, das ist

auch, wie gesagt, ein Thema, ähm, auf das ich

mich gar nicht fokussiert hab, weil ich

versucht hab, nicht zu viele Probleme in einem

zu lösen. Ich hab selbst diese, überlegt, ob ich diese

Sache mit den Class-Based-E-Mails und die Sache mit der

Test-Suite, ob ich die auseinanderziehen soll, weil es ja

im Endeffekt die Test-Suite einen

eigenständigen Nutzen hat, auch wenn ich

keine Class-Based-E-Mails

verwende. Das ist einfach nur ein Django-Ding.

Und man soll ja Packages eigentlich immer

so bauen, dass die nach Möglichkeit genau

ein Problem lösen, weil es auch dann einfacher zu

verkaufen, einfacher zu verstehen ist.

Von daher hab ich mich auch entschieden, dann da nicht

noch weitere Dinge reinzubauen.

Und auch persönlich, weil ich da halt auch

nicht so die Pain-Points hatte.

Okay. Also hast du eh schon konzentriert.

Immer Copy-Paste. Du musst es aber erst nicht bereitstellen

mit dem Package. Okay, verstehe ich.

Genau.

Ja. Klingt gut.

Aber jetzt kommen wir tatsächlich, glaube ich, dann zu

Django-Tasks, weil, wenn man ihm es verschicken möchte,

möchte man das ja wahrscheinlich nicht

sequenziell berechnen, oder?

Genau. Nicht dem Main-Thread.

Und genau.

Da gibt es ein neues

Konzept. Wie gesagt, das nennt sich Background-Workers.

Das lebt aktuell in einem Package namens

Django-Tasks. Da muss man aufpassen.

Es gibt ganz viele, die ähnlich klingen.

Django-Background-Tasks.

Ja, Background-Tasks-Manager.

Genau. Auf jeden Fall dieses Django-Tasks-Package.

Das ist von Jake Howard. Der hat das jetzt relativ schnell

zusammengenagelt. Das ist echt erstaunlich.

Der freut sich auf jeden Fall

über...

Doch, es ist nicht Django-Background-Tasks.

Ja, ich merke schon. Ich merke schon. Ich google hier.

Der freut sich

auf jeden Fall immer über Leute, die das ausprobieren.

Also wer von euch Interesse an Django hat,

möge das gerne anschauen.

Jetzt muss ich auch noch einen Satz sagen, was das überhaupt ist.

Ja. Genau.

Also in den meisten Projekten,

wenn man irgendwas asynchron machen möchte,

da meine ich jetzt gar nicht dieses

in ganzem Sinne relativ moderne Async, sondern einfach

ich möchte irgendwelche Prozesse nachgelagert machen.

Zum Beispiel irgendeine große Berechnung machen,

irgendeinen Cache befüllen oder halt auch eine E-Mail

schicken, weil ich möchte ja mit dem... E-Mail ist ja...

Ich muss ja mit der externen API kommunizieren,

um die E-Mail zu versenden. Da möchte ich ja im optimalen Fall

nicht meinen externen Thread blockieren.

Äh, meinen Main-Thread blockieren.

Ähm, und, ähm,

genau. Deshalb, ähm,

gibt es in jedem Projekt, in dem ich gearbeitet

habe, irgendeine Art von

asynchronem Processing. Meistens

in der Form von Celery. Ja, Celery.

Das ist in der Python-Welt sehr bekannt, in der Django-Welt.

Sehr gehasst und gefürchtet.

Ja. Ähm, gibt es

Django-Queue oder Queue2?

Ähm, gibt es, ist jetzt aufgekommen,

das ist, ähm,

ähm, das ist so eine leichtgewichtigere

Alternative, weil der, das Hauptproblem

ist, dass Celery erzwingt,

dass man irgendeinen Broker dazwischen stellt,

der als Message-Queue dient.

Ja, man kann das auch so konfigurieren,

dass der direkt die Datenbank nimmt, aber...

Oder der hat eine lokale Datei, in der er irgendwas reinschreiben kann,

dann macht er irgendeine SQLite noch extra auf.

Okay, das weiß ich.

Ja, aber ich glaube, man muss es nicht unbedingt,

also das ist üblich, ja. Und es ist auch,

also ich habe das mehrfach schon

gesucht und, ähm, für die

Result-Backends, also bei Celery,

wenn quasi, um die Ergebnisse zu speichern

und das im Endeffekt so eine Art Log, was

passiert ist, äh, dafür geht

das, das ist relativ einfach, aber für die,

für den Broker selbst bin ich zumindest immer

damit

gescheitert.

Ich war aber auch tatsächlich nie so viel

investiert darin. Auf jeden Fall, für die

allermeisten Cases ist es halt einfach harter

Overkill, wenn man da halt irgendeine Postgres oder MariaDP

hat, die kann in den, zum Beispiel

bei uns, in den meisten Fällen, kann die paar hundert

Tasks, die am Tag laufen,

problemlos abfrühstücken, ohne

dass sie da irgendwie in Verlegenheiten kommen.

Selbst bei ein paar tausend Tasks ist es immer noch kein

Problem. Vor allem, wenn man dann vielleicht auch

sagt, dass, ähm, die, äh,

dass die ein großer Task vielleicht auch eher nachts

läuft, für irgendwelche Sachen, dann,

und da ich auch keine Userlast habe,

und das wird allgemein, äh, sehr stark

als Overkill angesehen dazu, wie Dominik

gerade schon gesagt hat, viele Leute fürchten auf Celery

für, aus verschiedenen Gründen.

Ähm.

Das wird oft kaputt auch eingestellt, verhält sich komisch, aber vielleicht,

also ist die Frage, ob es an Celery liegt oder daran, dass

Async halt ein bisschen schwieriger ist?

Also, da, da, da würde ich gerne noch mal

kurz eine Begriffsklärung machen, weil

viele sagen ja, Async, ja, und ich höre

auch immer, wenn von Async die Rede

ist, dass dann Leute sagen so,

das, das merke ich dann irgendwie

nach einer gewissen Zeit, dass Leute eigentlich sowas wie Celery

meinen. Mhm. Aber das hat ja

jetzt mit, mit, zum Beispiel, mit, äh,

Async.io oder so, damit überhaupt

gar nichts zu tun ist, das ist ganz anderes. Ja, also,

Celery ist ein eigener Worker-Prozess, wenn ich dich

verstehe, der halt einfach Tastarbeite

zu einer bestimmten Zeit hat, die halt in der Liste stehen,

und dann also diese Queue, äh, leert.

Ja, du hast so eine Anzahl von, von Workern, und

du hast halt, äh, irgendwie, ähm,

genau ein Ding,

das halt eventuell auf so einer Queue drauf sitzt,

und dann verteilt es halt Jobs an diese Worker,

und, äh, die machen dann halt Dinge und

schreiben ihre, äh, Resultate wieder irgendwo hin.

Mhm. Ja. Und, ähm,

genau. Ich glaube, warum die Leute denken, dass es Async ist, weil das halt

meistens, wie schon gleich gesagt, nicht im Main-Prozess

läuft, obwohl man das auch machen kann, du kannst ja mit Django

mitstarten oder so. Mhm. Ähm, aber die Frage

ist auch da, was das halt heißt, also, weil,

äh, Jochen weiß das bestimmt besser,

weil es ja irgendwie verschiedene Event-Queues, die man

nutzen kann, G-Event oder Event,

irgendwas. Nee, nee, gar nicht, damit hat es

überhaupt nichts zu tun, also mit G-Event oder sowas hat es

überhaupt nichts zu tun. G-Event ist sowas wie Async.io,

ganz anderes. Aber kann man machen, also wenn man das mit Django

selber macht, dann muss man sich überlegen, welche da benutzt

wird? Ja, aber nicht, also nicht sowas wie

G-Event oder auch nicht sowas wie Async.io,

gar nicht. Also, das ist einfach was ganz anderes.

Das, äh, ist auch nicht, äh, eine Geschichte,

die im gleichen Prozess normalerweise stattfindet, sondern

du hast halt tatsächlich andere Prozesse.

Ja, wenn man die hat, genau, wenn man die

andere Prozesse hat, dann schon. Anders geht es

nicht. Äh,

okay. Also,

genau, anders geht, anders, jedenfalls

nicht, dass ich wüsste, dass das irgendwie anders gehen würde,

weil, wie soll das funktionieren, wenn du halt

jetzt irgendwie, äh, keine Ahnung,

in dem Reg, äh, also, nehmen wir an,

du,

du stößt halt an in einem

Request, also, du hast halt irgendwie einen Button, da steht drauf

Send E-Mail, drückst du auf E-Mail

und wie soll das jetzt gehen,

dass dann eine E-Mail,

ja, so, vielleicht geht es tatsächlich

irgendwie, aber das ist alles sehr hässlich, also,

äh, nee, du willst eigentlich

ein Task dafür starten, der ganz woanders

ist. Du hast recht, du willst das auf jeden Fall, da würde ich

dir auf jeden Fall zustimmen, aber ich glaube nicht, dass du mit

Definitiv. Ja, also, aber diese beiden Dinge haben

eigentlich nichts miteinander zu tun, auch wenn man das eine für das andere

vielleicht so halb irgendwie verwenden kann, aber

nee, das ist eigentlich was ganz anderes.

Wie gesagt, es ist halt,

es ist halt, also, die, wenn du dir,

wenn du quasi auf den Main Thread schaust,

dann läuft es halt irgendwie nicht da drin,

von daher liegt es halt nahe, das irgendwie asynchron

zu nennen, auch wenn das mit dem Async,

mit dem Python Async natürlich nichts zu tun hat,

technisch. Ja.

Genau, aber es

läuft halt nicht irgendwie Async,

sondern, oder in einem anderen Thread, sondern es läuft

in einem anderen Prozess. Ja. Also, hat überhaupt gar

nichts mehr mit dem Ding zu tun, mit dem

Interpreter da läuft, also,

ähm, ja, äh, genau.

Genau, und insgesamt, das

Celery Setup ist halt auch, äh, relativ,

es ist halt, da, da schießt man wirklich schon, äh,

auf, äh, also mit sehr großen

Kanonen. Ja. Weil ja meistens man dann mehrere

Worker hat, man hat einen Beat, der, der für,

für Scheduling, also der im Endeffekt diesen

Contab dann, dann ersetzt. Ja. Ähm,

dann gibt es noch dieses Monitoring Tool Flower,

ähm, was so mittelgut

funktioniert und eher schlecht als recht,

meiner Meinung nach, gewartet ist.

Ähm, nichtsdestotrotz, wenn man mal irgendwie reingucken möchte,

hilft es schon. Dazu, das kommt halt noch,

dass man, wie gesagt, meistens halt dann diesen, äh,

diesen Message Broker, ähm,

braucht, der halt dann meistens ein

Redis oder ein Revitim Queue oder

ein Derivat davon ist. Und das ist halt

für viele Projekte, vor allem am Anfang

ist das halt enormer, ist das ein enormer Setup

Aufwand. Wer das erste Mal in seinem Leben

Celery, ähm, einrichten muss,

ähm, der wird daran keinen Spaß haben.

Ja. Nicht, weil, wenn du halt zum Beispiel auf das Redis

sonst nichts anderes benutzt oder sowas, das läuft halt

halt die ganze Zeit rum, so irgendwie. Genau. Ja.

Und es, es bläht das Setup halt enorm

auf und es ist jetzt halt seit, seit

scheinbar auch Jahren ist es halt irgendwie allen bewusst,

dass es halt schon cool wäre, wenn Django da selber was

könnte und man halt eben nicht mit,

ähm, da, ne, mit, mit Celery

kommen muss. Wie gesagt, die Popularität von

Django Queue oder Q2, ähm,

wie das, äh, wie der Nachfolger davon heißt,

ähm, der ist ja tatsächlich jetzt auch nicht

aus der Welt, weil der im Endeffekt wirklich sehr, sehr

leichtgewichtig einfach nur halt

Dinge irgendwann außerhalb in einem

anderen Prozess abarbeitet. Und

die Idee von Jack Howard ist jetzt,

ähm, das wirklich in Django zu integrieren.

Er hat erst mal ein Package gemacht, wie man das halt

optimalerweise auch so macht, dass Leute es auch separat testen

können. Und, ähm,

das Ganze hat er vorgestellt.

Das war, ähm, ich weiß

nicht, ob es wirklich eine Keynote war, aber es war

auf jeden Fall de facto eine Keynote. Ich glaube, das

war das, was die Leute, wo die Leute am meisten und am heißesten

drauf waren. Ähm,

und das ist sehr spannend, weil, ähm,

ich tatsächlich auch bei mir in meinen diversen Projekten

glaube ich auch einfach aktiv zurückbauen würde,

ähm, weil ich einfach

happy damit wäre,

ähm, und aus der Celery Setup

in den allermeisten Fällen verzichten kann.

Es gibt jetzt wirklich Cases, wo man sagt, okay,

wir machen so viele, wir machen so komplizierte Dinge.

Das macht natürlich Sinn, da was

Explizites zu haben. Nur, wie immer, es macht

halt vor allem, wenn man jetzt auf ein Budget

achtet, ähm, macht

das natürlich schon Sinn, ähm,

da erst mal mit einer einfachen Lösung anzufangen.

Einer einfachen, soliden Lösung. Billig und

schnell rächt sich meistens irgendwann.

Ähm, genau.

Was übrigens auch ganz interessant war,

ähm, ich hab, äh, der, der

Talk von Carlton Gibson ging im Endeffekt

um mal wieder, HTMX ist super

und mit Alpine.js kann man zusammen coole

Dinge machen. Ja. Und sein Treiber

davon war, dass er halt sagt, dass

jetzt, wo wir in einer Zeit leben, wo die Zinsen

seit langer Zeit wieder ein bisschen höher

sind, Venture Capital deutlich, äh,

deutlich, deutlich seltener geworden

ist und deutlich kleinere, in deutlich

kleinere Mengen vergeben wird. Und dass

deshalb, ähm, dieses

ich hab ein Startup und ich möchte irgendwas ausprobieren,

dass die einfach mit viel weniger Geld die

Sachen bauen müssen. Und das ist halt nicht so, wir bauen

jetzt die in der perfekten Welt, sondern es muss schnell gehen,

es muss, es muss irgendwie solide sein,

aber es muss halt vor allem effizient sein.

Und dass er deshalb nochmal den HTMX-Tag verkauft hat,

was ich persönlich auch absolut unterschreiben würde.

Und das Interessante ist halt, dass

ich zum Beispiel hab jetzt noch nie,

ich mein, ich hab an ein paar Startup-Projekten mitgearbeitet,

aber jetzt nicht mit riesigem Venture Capital, das ist halt

eher so in deutschen Scales gewesen.

Ja, genau, da gibt's das auch nicht so.

Und es war immer für uns, also im

Agenturbusiness, wir haben halt ein Budget und das ist

eigentlich eher tendenziell zu klein

als zu groß. Ja, wie immer. Und, ähm,

das ist einfach, das ist interessant,

weil das, ja,

ich mein, wird ihm vorher auch schon klar gewesen,

aber das nochmal so auf den Punkt zu bringen

und dann zu sagen, ja, genauso sehe ich das auch,

weil, ja, natürlich kannst du, wenn du mit

React oder Vue, kannst du

ausgefallene Referenzen bauen, kannst du mehr Dinge

tun. Die Frage ist, brauchst

du das und schaffst du das in dem

Geld, das du hast? Und

das, finde ich, ist halt so der spannende USP da dran.

Ähm, klar, wenn man erst mal

seine komplette Applikation mit HTMX

ohne API gebaut hat und man kommt ein und sagt, ich möchte

das jetzt alles anders haben, ähm, das ist natürlich

auch nochmal teuer. Also, ich glaub, man muss da auch ein bisschen

in die, also, nicht nur sagen, wie viel Geld haben wir

jetzt, sondern wo geht das Ganze hin?

Ähm, nichtsdestotrotz persönlich finde ich das auch

sehr spannend. Der Talk war auch sehr cool

und sehr energetisch, wie

Carlton Gibson halt immer so ist. Ähm,

genau, war, war echt, äh, echt

super spannend.

Ähm, war, spielt,

ich glaub, dieses Django-Template-Partials

kommt halt auch irgendwie jetzt, ich weiß

rein, ich weiß nicht, ob das schon bei

5.1 war oder doch eher 5.2, wahrscheinlich eher

5.2, nehme ich mal an, ne? Ähm,

äh, oder hat er auch über

dieses, äh, Neapolit, äh,

äh, Neapolitan-Ring gesprochen,

was er da, das ist ja auch so ein

neue Quatsch-Views oder so. Ja, genau.

Also, das dreht sich alles um diese

Idee des, ähm,

Locality of Behavior. Ja. Ähm, Carlton

Gibson hat jetzt vor nicht allzu langer Zeit einen,

einen Newsletter angefangen, Stack Report

heißt der, wo er einmal im Monat

sehr ausführlich zu einem Thema schreibt. Ich

hab den abonniert, das kostet, glaub ich, irgendwie 5

Euro oder sowas. Ähm, bis jetzt hat

sich's, also, ich glaub, jetzt gibt's erst seit 2 oder

3 Monaten, bis jetzt hat sich's gelohnt, also ich mach

da gerne auch nochmal Werbung für ihn, unbezahlt. Ah, ja,

ja, ja. Ähm, das find ich echt, echt cool.

Ähm, äh, also es war echt

interessant, er hat jetzt über diverse Dinge

da geschrieben und es hat in dem aktuellen von

diesem Monat ging's halt um Locality of Behavior

und, ähm, er versucht halt im Endeffekt

das Konzept zu verkaufen, also er sagt

halt, dass wenn halt alles, was du brauchst, in

einer Datei steht, ist es halt einfacher zu verstehen.

Und er, er argumentiert

nicht, dass man alle guten

Principles, die man gelernt hat, sofort wegwirft,

sondern dass man halt dieses Premature Optimizing

aufhört, dass man sagt, okay, ich

mache, ich fang jetzt schon mit, weiß ich

nicht, die, die, die an und mach das alles perfekt

in vielen Dateien, ein Neueinsteiger in dem

Projekt hat keine, keine Chance zu verstehen, was eigentlich

passiert, sondern fangt erstmal klein an

und refactored, wenn die's wirklich braucht.

Ähm, weil viel von dem, ah ja, ich brauch's

nochmal, ich mach das mal irgendwie woanders hin,

kommt dann nachher mit, naja, ist

doch irgendwie anders geworden, war doch nicht so, wie ich's

mir gedacht hab und dann hat man halt immer diese doppelte

Refactoring-Schleife und dieses

Django Template Views ist halt die Idee,

äh, nicht, Django Template Partials,

Partials, sorry, Partials,

dass man halt wirklich sagen kann, okay, ich

diesen Block kann ich jetzt mit HTMX neu

rendern lassen, der ist aber trotzdem noch in der

großen Datei und ich muss es nicht zerpflücken, wie man's

halt vorher, also Stand jetzt mit

Vanilla Django macht, ähm,

und, ähm, diese Neapolitan

Crud Views ist auch die Idee, dass du halt wirklich mehr

Sachen in einer, an einer Stelle zusammen

hast. Dass man im Grunde eine, eine Klasse hat, wo die

ganzen, also Get Post und sonst wie Dinge,

die da passieren, halt alle drin sind, äh,

genau, ja. Ich persönlich

finde, dass, äh, Locality of Behavior ist, glaub ich,

eine, eine gute Sache, ich mein, das geht auch so ein bisschen nach

Jagni, also You Ain't Gonna Need It,

ähm, dass man halt nicht, dass man erst mal überlegt,

so muss ich jetzt wirklich anfangen,

alles so hoch zu skalieren, wie es unbedingt

notwendig ist. Nichtsdestotrotz,

wenn ich halt in einem Projekt, wenn ich weiß, ein Projekt

wird eine gewisse Größe erreichen,

die Dinge zu tun, die ich jetzt schon

weiß, die sinnvoll sind, ähm,

glaube ich, dass man sich da dann andererseits auch

wieder ein paar Refactoring-Zyklen spart,

aber ich glaube, generell ist man schon sehr

prone, als Entwickler over zu

ingenieren und ich glaube, das sich im Kopf zu behalten,

so muss ich das jetzt wirklich tun.

Ja, also so ein bisschen so ein Trade-off, ne, mit KISS oder so was

und schon simpel und dass du irgendwie tatsächlich

versuchst, vielleicht, also was ich zum Beispiel

finde, ist, dass wenn halt zu viele Sachen in einer

Datei drinstehen, selbst wenn das irgendwie am Anfang

überblicklich ist, wird es halt auch dann wieder hässlich.

Und wenn eine gute Modulstruktur

darunter liegt einfach, also einfach nur vom

Namespacing her, hilft das fast

am meisten, finde ich. Ja.

Ähm, was dann auch gar nicht so schwer zu verstehen

macht, wenn das halt alles in einem Directory liegt, zum Beispiel,

dann ist das schon vielleicht ein bisschen näher dran. Aber wenn das

Directory dann groß wird, dann ist das wieder ein Problem.

Ne, das ist so, ja.

Oh, ich würde ganz kurz

nur einmal kurz einwerfen

nochmal zu dieser Task-Geschichte,

was ich halt oft sehe, was ich finde,

was man vermeiden sollte,

wenn Leute sowas machen

und das halt irgendwie, weil oft

macht man das dann ja, man braucht's

schon meistens, aber dann doch nicht

irgendwie so dauernd, dass man da,

dass alle Leute da irgendwie

viel Erfahrung mit hätten.

Und was ich jetzt schon häufiger gesehen

habe und was in der Praxis dann so

zusätzlich zu diesem ganzen

Infrastruktur-Ding auch nochmal ordentlich Schmerzen macht,

ist halt, wenn Leute anfangen,

irgendwie so ganz Kaskaden von Tasks

irgendwie zu schreiben,

so gerade bei Celery ist das dann halt auch

sehr einfach, ne, und dann hat man mal da Abhängigkeiten

dazwischen und dann, und Leuten

ist gar nicht so bewusst, dass es bedeutet, ja,

es geht jedes Mal über eine Prozessgrenze, dann wird da

irgendwie wieder irgendwas wieder realisiert, dann muss der

Kanzlerrahmen wieder so raussehen, wie das realisiert wird,

dann geht's irgendwo zwischendurch schief und dann hast du halt

irgendwie so ein

explodiertes Gedärm irgendwie, was da rumliegt

und was das halt so steht.

Und, also was ich nur empfehlen kann,

ist, man macht halt eine Funktion oder so

eine Methode an irgendeinem Modell oder so,

wo man halt das, was man tun möchte, halt reinschreibt

und dann testet man das ganz normal, synchron,

irgendwie, wie man

Sachen halt so testet und dann

sagt man in einem Celery-Task

eigentlich nur, okay, man ruft halt dieses Ding auf,

fertig. Wie man auch

im Vue schreiben würde, möglichst schlank

und eigentlich nur die Dinge

komponieren, denn wirklich da implementieren.

Ja, und keine Logik in die

Tasks packen, sondern

von den Tasks, also in den eigentlichen

Celery-Tasks immer nur irgendwie Logik,

die irgendwo anders ist, aufrufen.

Aber wenn du halt Logik hast, oder am besten Logik verteilt über mehrere Tasks,

dann passieren scharröckelige

Dinge unter Umständen und

ja. Absolut.

Genau, das war nur so ein kurzer Einwurf.

Ich hab da noch

so ein tolles Thread zu

im Chaos Social,

den du auch, wo du den Link vorhin geteilt hast,

der sehr interessant war.

Einige coole Leute, unter anderem

Carlton Gibson selber und der Hüneck und so.

Ja, Hüneck, genau, und diverse Leute,

da gab's ein Thread zu,

was braucht man jetzt bei Background-Tasks eigentlich alles?

Ja. Und was sind da die Anforderungen

genau? Und was ist auch in der Praxis?

Neugeschrieben oder anders implementiert, genau. Und auch alle haben sich

über Celery beschwert aus Gründen.

Ja, ich kann das mal, ich kann, ja genau, das Ding

verlinke ich auch mal. Ja, Fettyverse

ist halt zur Zeit, also wenn er noch nicht ist,

da sind halt alle,

also. Es steht tatsächlich auf meiner Liste und ich lese

halt immer so ein bisschen mit, aber naja.

Ja, also da ist, also das fühlt sich an

wie so Twitter früher, so

ein bisschen Blümchenwiese-mäßig.

Alle Leute sind, oder viele, viele

der Leute, die man so kennt, sind halt da.

Und man kann sich mit denen

einfach so unterhalten und so, ja.

Ja, cool. Genau.

Ja.

Ja, ist ein interessantes Thema.

Genau. Und ich bin, was ich auch

interessant fand, die,

ich hab mit auf der Konferenz noch ein Wort

mit dem Creator da

gewechselt und er meinte

auch, dass früher wurde,

also wenn ich's richtig verstanden hab, ich will ihm jetzt keine Worte

in den Mund legen, aber wenn ich's richtig verstanden hab, meint er,

dass früher bei Django eher so die Idee war,

alles, was nach Core kommt, muss

mehr oder weniger so die

eierlegende Wollmilchsau, 110%-Lösung

sein, weil das ist ja Django, das muss ja so.

Und jetzt war halt die Idee wirklich zu

sagen, naja, aber lass uns doch erst mal mit was anfangen,

was halt alleine steht, also dieser MVP-Gedanke.

Und natürlich kann man noch 400

Sachen nach und dazu bauen, aber

braucht man die wirklich?

Will das die Crowd

so? Und dass die jetzt wirklich anfangen

und versuchen,

ja, also wirklich mit einem kleinen,

mit einem kleinen Inkrement zu shippen,

dass das halt stehen kann, das laufen

kann und alles, was halt danach

kommt, einfach zu gucken, wie reagieren

die Leute, so was für Sachen werden wirklich angefragt.

Das finde ich halt sehr interessant, weil ich glaube, das ist

einfach so ein generelles Ding, wenn man irgendwie

in der Softwareentwicklung ist, dieser MVP-Gedanke ist so,

so, so zentral

und da kann man so viel falsch machen und so viel Geld

und Projekte und Chaos verlieren,

wenn man halt nicht

dem MVP denkt.

Weil schöner geht halt immer

und ja,

genau.

Ja, und genau, bei

Ruby on Rails ist halt auch

diese Background-House-Geschichte schon

seit Ewigkeiten drin und

das war halt mal eine der Geschichten, die in Django halt,

ja, wo man da halt irgendwie dann immer sagen

musste, ja, nimm halt Terri,

ja, es tut weh, nimm's halt trotzdem,

das ist das, was es gibt.

Ja, und

das, wenn sich das jetzt ändert,

dann ist auf jeden Fall ein Pain-Point irgendwie

auch weniger.

Ja, also die haben gesagt,

dass wenn es gut läuft, landet das mit 5.2,

du weißt, wann 5.2 rauskommt,

hattest du gesagt?

April, ja.

Genau. Dann wird dann neben meinem

kleinen Testhelper das zweite

große Ding werden dann die Background-House.

Oh. Sehr gut, sehr gut.

Ähm,

genau.

Ja, also, HTMX war diesmal

auf der DjangoCon also auch quasi wieder so ein,

es ist ja die letzten Male eigentlich immer ein großes Thema gewesen.

Genau.

Ja, ich mein, HTMX ist halt,

ist halt im Endeffekt die Silver Bullet mit,

der sehr, sehr viele Leute dann hat im Existenzbereich.

vermeiden können.

HTMLX-JavaScript vermeiden können, sorry.

Was natürlich so ein bisschen

ein Gänsefüßchen ist, aber natürlich immer noch ein bisschen

JavaScript braucht und das auch selber mit JavaScript geschrieben ist.

Nichtsdestotrotz

vermeidet das halt, dass man in Projekten

JavaScript verwenden muss,

was natürlich für viele tendenziell eher

Backendler, wie ja Django aktuell

verwendet wird, weil es ja auch ein sehr data-driven Framework ist.

Das ist

natürlich sehr angenehm, da zähle ich mich auch dazu.

Ich habe es auch irgendwie nie geschafft,

mich ernsthaft mit einem

JavaScript-Framework zu beschäftigen und

ich

bin auch in meinem Beruf immer wieder damit konfrontiert,

bei den Entscheidungen, wenn man

ein neues Projekt startet, was nehmen wir jetzt?

Wir haben uns jetzt tatsächlich bei dem letzten Projekt, das gestartet ist,

auch aktiv für HTMLX entschieden.

Auch mit einem Team, die tendenziell

eher JavaScript-Front-Endy

sind.

Oh, ja, das ist natürlich interessant.

Und weil wir einfach auch

gesagt haben, wir glauben, es ist immer halt, dass

das Projekt ist halt so eine ganz klassische

Backend-Applikation, man hat viele Listen, man hat viele

Crud-Views, es gibt zwei, drei, vier

Sachen, die so ein bisschen ausgefallen

sind, aber auch nicht so wirklich. Also

da hat man mal so ein Drag-and-Drop-Element oder sowas

und wir sind einfach der Meinung,

dass man das dafür

halt HTMLX wirklich gut funktioniert,

weil das ist das, was Django wirklich gut kann.

Und

das Projekt ist es auch nicht

etwas, wo man sagt, das ist jetzt irgendwie,

wenn die Firma durch die

Decke geht, dann so und so, sondern das

wird immer eine Backend-Applikation bleiben.

Logischerweise wird die wachsen, wenn die Firma wächst,

etc.

Aber das wirkt

einfach nach dem perfekten

Hammer für diesen Nagel, was

nicht heißt, dass wenn man jetzt sagt, ich möchte

keine Ahnung, das nächste Instagram oder

sowas bauen, dass das vielleicht, wenn man schon

die Kohle dafür hat am Anfang, dass das

vielleicht nicht unbedingt die beste Wahl ist.

Geht wahrscheinlich auch alles trotzdem,

aber ich glaube, umso mehr

sage ich mal, wirkliche Endnutzer,

also jetzt nicht Mitarbeiter der Firma oder Administratoren,

sondern wirkliche Endnutzer, man auf der Plattform hat

wahrscheinlich schwingt da dann immer so die

die Notwendigkeit für ein

richtiges, volles Frontend-Framework, wo man

das ja auch in Gänzefüßen sehen muss, React und Vue sind ja auch

keine Frontend-Libraries,

schwingt dann doch eher so das Pendel in

diese Richtung.

Und ich glaube, diese Frage kann man halt wie

jede einzelne Tech-Frage damit beantworten.

Es kommt drauf an.

Nichtsdestotrotz wird das natürlich hart gefeiert

in der Community, weil, wie das auch bei mir so ist,

das ist es halt, ich meine, wie gesagt, ich bin seit

zwölf Jahren dabei, das erste Mal,

dass man, dass ich jetzt wirklich

ein Werkzeug bekomme,

das vernünftig funktioniert.

Und das, was man früher so immer gemacht hat,

wie JQuery und sowas, definiere ich

nicht als vernünftig funktionieren.

Ja, das hat nicht, also es ging,

also man kommt damit erstaunlich, aber das hat nie wirklich

gut funktioniert, das ist richtig, ja.

Wobei ich

eine Sache hinzufügen würde, etwas, was

ich in letzter Zeit auch häufiger mache und wo ich auch

denke, oh, das ist auch alles gar nicht schlecht und es geht in die

richtige Richtung, sind halt so Web-Components,

das ist eigentlich auch ganz nett, es ist,

da muss man dann halt JavaScript schreiben, das ist halt

so ein bisschen doof, aber

man kann halt irgendwie, das hält

sich dann auch nicht so gut.

Man kann halt in Grenzen, also, und

man weiß halt, also, das ist, habe ich

letztens wieder erlebt und es tut jedes Mal weh,

irgendwie, größere

Projekte, die man lange nicht angefasst hat, irgendwie,

das ist immer schmerzhaft, also

wenn man jetzt irgendwie,

ja, da so, zum Beispiel, das war

jetzt mein View-Projekt, es ist halt,

irgendwas geht nicht mehr

und es dauert immer, bis man rausgefunden hat,

was denn da jetzt eigentlich das Problem ist und bis das

alles wieder rund läuft und dann

vergehen vielleicht auch nochmal ein paar Tage oder

Wochen, bis man wirklich alles gefunden hat, was vielleicht nicht

mehr ging, weil manchmal war es, es ist nicht so offensichtlich

und das ist einfach total nervtötend,

also, und

genau, das Problem hat man mit Web-Components

halt auch nicht, weil das ist halt Standard und

das, wenn das jetzt funktioniert,

funktioniert das in 10 Jahren

halt auch noch ganz genauso und

ja.

Tatsächlich haben wir zu dem Projekt mal Django-Components

ausprobiert, das ist ja auch eine von diesen vielen

Ansätzen, da gibt es auch Django-Slippers und wie die alle heißen,

um, um,

das letzte, Django-Slippers,

um,

um,

im Endeffekt dieses Komponentendenken

in die Django-Welt zu bringen,

weil de facto die Django-Template-Welt

ist ja immer noch, wie sie vor 15 Jahren mal

irgendwann angefangen hat und da zu

überlegen, dass man Komponenten bauen möchte,

vor allem in so einer Kombination mit Tailwind, die ja

dann eher diese Utility-Based-Klasse,

also ein normales Tailwind-Diff

hat noch 10, 15 Klassen,

das eskaliert

ziemlich hart. Ich finde es gut,

aber wie gesagt, das ist nicht

schön anzugucken und von daher die Sachen eher

zu kapseln und zu sagen, ich habe jetzt nicht, wie bei

Bootstrap zum Beispiel früher,

ich habe hier eine Button-Klasse und dann sieht die da Button halt so aus,

wenn ich was überschreiben muss, bin ich halt

arm dran, dann wird es schwierig,

sondern dass man halt wirklich die Sachen individuell

mit diesen Klassen halt definieren kann,

ohne halt die ganze CSS-Magie dahinter 100%

verstehen zu müssen und

da diese Komponenten in der Django-Welt

zu machen, klingt super interessant.

Das konnte man vorher auch schon mit Includes machen.

Ja genau, mit Includes, ja. Es gibt auch eine neue Version

von Includes irgendwie, die das so ein bisschen

zwischenspeichern können irgendwie auch.

Ja, auf jeden Fall, da gibt es Packages,

die explizit dafür da sind, um diese

Frontend-Learnings auch in die Django-Welt

zu bringen. Wir haben uns jetzt für Django-Components entschieden.

Das scheint auch okay gut zu

funktionieren. Habe auch von einem Freund

gehört, der das ausprobiert hat, der da meinte, dass er

damit gut, der eigentlich auch sehr viel

und gerne im Frontend gemacht hat, jetzt aber aus

besagten Effizienzgründen halt gewechselt

ist und

genau, das

ist auf jeden Fall eine interessante Sache. Also wer

sich damit beschäftigt und halt ein

Frontend bauen möchte, für das man sich in 2024

nicht schämen muss, dann glaube ich,

ist diese HTMX, AlpineJS und dann

irgendwas an diesen Komponenten-Libraries, die sich gerade,

die emergieren gerade alle. Also ich glaube, da gibt es noch nicht so

diesen de facto Standard.

Aber wenn man sich da so ein bisschen

reinliest, da findet man relativ,

also nicht viel, viel, aber da gibt es

auf jeden Fall schon Inhalte und

da kann man sich am Ende vielleicht auch irgendwas ausruhen.

Das ist alles nicht so kompliziert,

was einem gefällt.

Habt ihr mal schon mal herumgespielt mit

dem HTMX-Ding

für Mobile?

Also in einem Hypermedia

Systems Buch das letzte

Kapitel, wo es dann

darum geht, dass man das Ganze auch in Mobile einsetzen

kann oder soll oder so.

Als

so

Ja, so eine Art von XML-Endpunkt,

die dann irgendwie gerendert werden

kann von, ich glaube React war es

tatsächlich, React Native. Ach so, ja.

Und dann Apps hat auf dem

Telefon, die dann diese einzelnen Komponenten

halt mitziehen können, einfach

von deinem normalen Endpunkt.

Ja, klingt wild. Ich hab's noch nicht,

nee, hab ich nicht angeguckt.

Also ich hab auch für

für so

Mobile, finde ich, eigentlich sind die Webviews

oder wie heißen die noch?

Progressive Web Apps, genau.

Ist eigentlich eine sehr, sehr schicke

Geschichte. Geht auf iOS auch deutlich

mehr inzwischen als früher. Wurden die nicht

irgendwie gebannt? Nee.

Ah ja, Apple hat da gedroht,

aber das ist dann nicht passiert.

Glücklicherweise. Ja, hat doch

ein bisschen zu viel Gegenwind gegeben.

Ja, und

ich denke, dass man vieles, was

halt man irgendwie

vielleicht mit nativen Apps früher gemacht hat,

auch mit, ja genau,

Progressive Web Apps hinbekommt

und

ansonsten sind halt die Mobile

Geschichten halt immer so eine komplizierte Geschichte, wenn man da

wirklich eigene, ist halt, ich meine

für manche Sachen, wenn man eh

dafür ein Team hat und genug Geld,

dann kann man schon machen. Also ich würde das tatsächlich irgendwie mal

ausprobieren. Ich finde diesen Ansatz ganz cool.

Ja, ausprobieren.

Ja, für Mobile

auszuprobieren, das klingt irgendwie super.

Das ist der selbe Standard da und das selbe

Prinzip. Ist jetzt eigentlich, glaube ich,

eine ganz gute Überleitung zu dem nächsten

Minithema, nämlich Lightning Talks.

Wer es nicht kennt,

die Lightning Talks, das ist bei

den Django-Cons zumindest, ich war noch auf keiner anderen Konferenz,

aber ich glaube, es gibt es auch an anderen Konferenzen,

die ist jetzt am Ende des Tages

fünf bis zehn Leute einen

hart getimten fünf Minuten

Maximal-Vortrag halten können bei

irgendeinem Thema. Das heißt, die Vorbereitung ist

sehr gering bis nicht vorhanden

bei den Leuten. Aber das ist ja cool.

Der coolste Vortrag, den ich gehört habe, war

Fuck it. Zwei Minuten.

Und die Idee

dahinter ist einfach, genau das, was du

gerade gesagt hast. Ey, ich habe dann im Buch dieses Kapitel gelesen,

finde ich da halt spannend, habe ich noch nicht ausprobiert,

wollte ich euch mal mitgeben. Oder was ich

vorhin gemacht habe. Ey, es gibt Django Components, wer sich

dafür interessiert, schau ich das mal an.

Und da ist normalerweise die

Informationsdichte sehr hoch

und auch die Unterhaltungsdichte sehr hoch,

weil natürlich Leute auch dann einfach mal einen Spaßvortrag machen

oder irgendwas Absurdes aus ihrem

Alltag erzählen.

Kannst du dann Ukulele mitbringen?

Genau. Und ich finde,

wir haben jetzt das auch bei uns

intern in unserer, also bei

meiner Firma,

bei den internen Barcamps

so gemacht, dass wir auch einen expliziten

Lighting Talk Blog haben, weil viel

von so Content-Teilen

und Wissensmanagement scheitert daran, dass die Leute

sich wirklich aufraffen müssen, Sachen

vorzubereiten, Sachen zu recherchieren. Es gibt gewisse

Ansprüche, die Leute an sich haben. Es gibt vielleicht

Erwartungshaltungen, die existieren

mögen oder nicht existieren mögen. Aber so ein

Lighting Talk gibt es das halt nicht. Du stellst dich

da hin oder in dem Fall jetzt in der

Post-Corona-Neuen-Moderne.

Du sitzt dann hinter, vor deiner Webcam

und teilst dann halt kurz deinen Browser oder deine

zwei Slides und sagst, Leute, das habe ich

gesehen, das habe ich gelernt voll gut

oder auch voll kacke.

Und das ist ein echt

cooles Format, den man auch, wie gesagt, gut glaube ich

in Firmen oder auf Meetups

auch sehr gut, wir haben

mal vor ein paar Monaten, ich glaube

im Februar diesen Jahres, haben wir eine komplette

Lighting Talk Session gemacht

beim Django Meetup Köln hier

und das ist echt ein

cooles Format, was

viele von den Problemen löst, die man

sonst so hat, wenn man

Content teilen möchte.

Ja, ich finde auch, gerade in jedem Format, also das

irgendwie für Konferenzen oder Barcamp oder was man

auch immer hat, wo man zusammen arbeitet, ist dieses

Lighting Camp, äh, Lighting Camp zeige ich schon,

das Lighting Talk Format echt

cool geeignet, um so ein bisschen

lockere Atmosphäre reinzubringen, entweder

am Ende eines Tages oder am Anfang von diesem

wir teilen uns irgendwelche Sessions auf Dingen, so kurze

Slots, selbst wenn es nur eine Viertelstunde ist,

zwei Minuten oder eine halbe oder sowas, um

so ein bisschen mit den Leuten so reinzukommen,

das ist echt schön, ich glaube auch außerhalb vom Coding

ehrlicherweise. Man muss halt, glaube ich, immer noch

so auffassen, dass man halt wirklich hart guckt,

dass die nicht überschritten werden, weil

einige Leute dann ihr Co-Referat halten, dass dann doch ein bisschen länger

wird. Ja, das

nervt die meisten immer, glaube ich,

aber ja. Und eine andere super

Sache ist halt auch einfach mal ein Gefühl zu bekommen,

ob man selber mal einen Vortrag halten möchte. Eingangs habe ich ja

gesagt, das war echt eine richtig coole Erfahrung

und ich habe auf der letzten

Konferenz in Edinburgh

habe ich auch einfach mal einen Lightning Talk gehalten,

um mal zu sehen, um mal

so den Fuß ins Wasser zu halten, wie ist das

überhaupt so? Über was?

Um den Fuß ins Wasser zu halten.

Über was? Ach so. Über Füße ins Wasser halten, also kein

Lightning Talk. Nein. Nur

über Füße ins Wasser.

Angeln mit den Zehen.

Das war die Frage.

Ich habe tatsächlich,

keine Ahnung, ich habe dieses Jahr einen über

meinen Django Migration Zero Package

gehalten.

Ich beantworte meine Frage aber mit diesem Jahr,

weil ich es beim letzten Mal vergessen habe.

Ist ganz cool, es ist ein Pattern, das hat sich

2018 jemand ausgedacht. Wer schon mal mit

Django Migrations gearbeitet hat und

länger auf einem Projekt war, weiß, da sammeln sich ziemlich

viele Migrations nach kürzester Zeit an.

Diese Migrations, wenn man die volle

Kontrolle über seine Datenbank hat,

also zum Beispiel beim Package hat man das nicht, weil das installiert

sich irgendjemand und dann macht irgendwer was damit.

Das ist außerhalb der Macht,

des Creators. Aber in so einer klassischen

Applikation, die man baut, hat man eigentlich die volle

Kontrolle über die Datenbanken. Dann ist irgendwann

es auf dem letzten

Produktivis-System angekommen und die Migrationen haben de facto

eigentlich keinen Wert mehr, außer vielleicht einen historischen,

der aber auch sehr relativ zu sehen ist,

weil abgesehen von natürlich Custom-Datenmigration

die ganzen Sachen auch im Git irgendwie, die ganzen

Modeländerungen hinterlegt sind.

Viele Migrationen führen dazu,

dass die Tests langsamer laufen, dass die

Test-Datenbank aufgebaut wird, weil

oft ist es ja so, dass es ja nicht ist, man

fügt immer was hinzu, sondern da kommt was hinzu,

da kommt wieder was weg, dann habe ich was geändert, dann habe ich zum

18. Mal irgendwas geändert. Und

Django bietet dafür eine Möglichkeit an, das nennt sich

Squash Migrations, um das aufzuräumen.

Das Problem ist, das kann sehr, sehr schlecht mit

Circular Imports umgehen.

Also sprich, ich habe einen User

und der hat ein Projekt und das Projekt

hat, keine Ahnung, Kommentare

und die Kommentare haben wieder den User.

Das heißt, man muss dann, wenn man das macht,

diese Migrationen sehr

stark auseinanderziehen. Also wie man das

bei Circular Imports machen würde, das ist ja ein generelles

Python-Thema. Und das

ist sehr, sehr mühsam, was dazu führt.

Lazy importieren und die Sachen da als Strings hinschreiben.

Genau. Und wie das halt dann immer so ist

mit Sachen, die mühsam sind, die Leute machen

sie nicht. Umso einfacher Sachen sind, umso schneller

werden und umso besser werden sie getan.

Und es gibt einen Pattern, das nennt sich Migration Zero

und das hat sich jemand bei

Medium 2018 ausgedacht, da sitzt er schon

eine Weile. Und die Idee ist halt einfach

auf Deutsch gesagt, du löscht halt einfach

alles, haust alles weg, was du hast und lässt einfach

Django initial

neue Migrationen erstellen. Das

klappt auch für große Projekte sehr gut

Also ich hatte das beim richtig großen Projekt

mit großem Entwicklungsteam, 5-6

Jahre Laufzeit, hatte ich einen Mini-Konflikt

der aber auch so offensichtlich war, dass ich ihn sofort

lösen konnte. Also es war wirklich gar kein Problem

und da habe ich halt dann dieses Package gebaut,

das dieses Pattern

implementiert und das ist im Endeffekt

ein zweistufiges Ding. Einmal habe ich einen Helfer gebaut,

der halt einem Verein quasi durch alle Apps

geht, die Sachen aufräumt, weil das tatsächlich auch, wenn man

das öfter macht, ist es, je nachdem wie viele Apps man hat,

ist es auch Arbeit, auch wenn es doof klingt.

Und das zweite ist ein Skript, das in die Pipeline

geht, weil Django hat ja alle Migrationen,

werden in der Datenbank in so einer

ja, in so einem Log, in so einer

Historientabelle hinterlegt, da quasi noch

die Änderungen anpasst.

Das heißt, du kannst es einfach in die Pipeline hängen, du hast

den Django-Admin in Switch, du kannst sagen, ja, jetzt habe ich

Migration gelöscht, jetzt bitte beim nächsten Deployment

lass bitte, bereite bitte die Datenbank

auf, um diesen Prozess zu streamlinen

und das ist ein Thema, das verkauft

sich sehr schwer, weil

es ist halt, wie wahrscheinlich es auch

der geneigte Zuhörer gemerkt hat,

relativ tief und auch nur so ein

Edge-Case, eigentlich sollte man es tun, aber so richtig Lust hat da keiner

drauf.