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.

Das sind keine News.

Wann war die nicht angekommen?

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

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.

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 ja 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. Also wir haben ja jetzt schon einige

Zeit keine Sendung mehr.

Das ist 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 sind jetzt, was, alles zu teuer mit dem 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, 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 gewachsen.

Aber ich bin mal gespannt, ob das klappt.

ob sie da jetzt irgendwie, keine Ahnung,

äquivalent rekrutieren können.

Mal sehen.

Aber ja.

Ja, dann 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 schon mal irgendwie,

aber normalerweise ist das ja nie passiert.

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

Und jetzt, und welche, hat man das irgendwie so rückgebaut?

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 rein interpretieren, das ist schon richtig.

Es gibt tatsächlich von Python 3.13

jetzt so erste Beta-Versionen.

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.

Python 3.13 kann man auf jeden Fall jetzt mal so.

Jetzt ist der richtige Zeitpunkt, um das mal auszuprobieren.

Was habe ich 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 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

Passwortmanager 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 da,

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 die

Das kostet, 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, ja.

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.

Ja, genau. Was haben wir noch? Achso, ja, es gibt auch gute Nachrichten. 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 Pip installieren würde dann halt nicht mehr funktionieren.

Und die haben jetzt gerade auf der Python 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 zwei, drei Wochen

ist NumPy 2.0 erschienen.

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

Das war eine ganze Zeit lang in Progress.

Und

genau, ist vielleicht

jetzt nicht der günstigste Moment, um zu steigen,

sondern man sollte vielleicht das erst mal auf

kleiner zwei pinnen oder so und dann mal gucken,

bis alle anderen irgendwie sich

angepasst haben, weil das bricht halt

einige

Geschichten. Aber ja,

schön, dass es jetzt raus ist und dann

es macht einige...

Wie gesagt, ich habe keine

Ahnung, was alles genau passiert ist oder ich wusste es mal,

hab es wieder vergessen.

ja, Performance ist irgendwie besser geworden.

Es sind auch ein paar Updates, das heißt,

ihr müsst ein bisschen aufpassen, weil wenn ihr da irgendwie einfach

updatet, dann kann es sein, dass euch

relativ viele Dinge kaputt gehen.

Also ich habe 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,

das ist eigentlich super, dass man

halt, das ist auch eh ein Semantic-Version-Ding,

2.0, Breaking-Api-Changes,

what happens. Genau.

Genau, dann gibt's

eine neue, also eine erste

1.0-Release von Polars,

was ja auch vielleicht ganz

nett ist, dass man sich

jetzt halt so drauf 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

Pandas oder ist das egal? Ich nutze eher Pandas,

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

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

Ja. Pandas haben die auch ein bisschen schneller gemacht. Ich weiß gar nicht,

gibt es 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 habe mich an diese, also viele Sachen

sind halt auch total komisch. Und ich habe mich halt dran gewöhnt.

Zum Beispiel an diese Multi-Index-Geschichten

und so. Und

wahrscheinlich ist es keine gute Idee. Und es ist richtig,

dass Bollers das alles nicht gemacht hat. Und auch selbst

die Leute, die Pandas gebaut haben.

McKinney sagt heute im Podcast so,

ja, das mit diesen ganzen komplizierten Index-Geschichten

und so, das war wahrscheinlich alles nicht so richtig.

Aber 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

Polas ist schon der richtige Weg eigentlich.

Ja, genau.

Was gibt es noch? Psycho-PG

3.2 ist raus, also

auch etwas, ich weiß

nicht, ob alle schon umgestiegen sind auf 3,

also ich habe das wahrscheinlich...

Es gab ja Psycho-PG 2 explizit

und wenn man jetzt aber normal Psycho-PG nimmt,

dann ist das jetzt normal 3. Ja, genau.

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 Seiko BD?

Warte mal, lass mal grad gucken.

Bestimmt auch bei Tifa.

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

Minimum steht da nicht.

Nee, steht, steht,

ich weiß es. Keine Low-Hanging Fruit.

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

Oder sie haben es kontinuiert und haben dann vergessen,

dass es irgendwie ...

Aber in der Praxis sehe ich ganz oft alte Datenbanken.

Ja, stimmt.

Und 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

eben, wenn ich jetzt mir angucke, so

Postgres 12 oder so, was ich häufig sehe, oder

äh, selbst, also

bis, wenn man jetzt stattdessen ein

Postgres 16 nimmt, dann ist es halt schon, da hat sich

schon einiges getan, also

kriegt man irgendwie so 30% Performance

Proofment einfach so gerade.

Ja, also, ja.

Genau, ähm,

ja, äh, dann, oh,

HTMLX 2.0 ist erschienen,

auch ganz interessant, da hat sich auch nichts

geändert, sondern das ist einfach nur

hochgezählt und

gut, ist ein paar Sachen entfernt worden.

Also ein paar Extensions,

die Websockers-Extension ist nicht mehr drin

oder ein paar Dinger.

Genau.

Du benutzt das immer noch so gern?

Ich benutze das immer noch super gern.

Ich auch. Ich habe es auch jetzt letztens wieder

in einem Projekt gehabt

und das war echt

total super.

Wie würdest du denn einen Chat umsetzen?

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

ob das so viel Spaß macht, weil da ist ja

manchmal vielleicht die Echtzeit dann tatsächlich,

wenn die 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 ein Deployment

mache und ich restarte das Ding?

Was passiert denn da mit der Verbindung?

Ist sie 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 mit dem Server

eine Frage und nicht einem anderen

Menschen.

Nee, da brauchst du es nicht. Achso, du meinst jetzt so was

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 gechankt jetzt, oder?

Ja, du kannst einfach

mal da rauskommen, kannst

ja das anzeigen,

das geht.

Genau.

Ja, genau, das ist auch so was.

Genau, dafür braucht man

keine

direktionale

Verbindung oder keine stehende Verbindung.

Okay, dann

5.1 hast du noch.

5.1 Alpha erschienen, genau.

Ich weiß nicht,

ob hier irgendjemand genau die Liste der

Neuigkeiten und so 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,

Query-String, super, das habe ich hier halt schon ein paar Mal

selber gebaut. Aber warum gibt es das denn nicht?

Genau, also das Problem

ist, wenn man quasi

ein paar

Dinge hinzufügen

will zu einem Query-String, zum Beispiel, wenn man

irgendeinen Filter angeschaltet hat oder so,

dann ist halt die Frage, okay,

aber da sind jetzt möglicherweise schon Sachen gesetzt

und dann muss man das irgendwie,

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.

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

dabei sind. Es sind nicht die großen Game-Changer,

die sind jetzt eher dann für 5.2, glaube ich, geplant.

Später mehr.

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

Ja.

Ja, ja, ja, ja.

Middleware to require authentication

by default. Keine Ahnung, was das ist.

Aber ich würde sagen, über die ganzen Neuigkeiten bei Django,

da können wir doch tatsächlich den Ronny gleich besser fragen,

weil der von Django-Con wahrscheinlich mehr erzählen kann,

als er aus dem 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 der 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 DangoCon, lieber Ronny.

Also ich hab, du, 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 Django. Ich habe 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.

Und

bin jetzt seit vielen Jahren

Tech Evangelist in meiner

Firma. Ich arbeite bei der Agentur

Ambient in Köln und

habe 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-Stage. 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ß dran 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. Das löst 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 ein 50s-Based-Template hat, 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 hatten, Plaintext-Part-Inhalt, Übersetzungen, bestimmte Header, bestimmte Variablen, die für das Base-Template 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, 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, dass man auf diese Liste so ein bisschen wie in einem Query-Set zugreifen kann.

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

immer so schnell geredet wie ich.

Ich weiß es nicht. Ich habe mir 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, wäre es noch nicht

gemacht hat, geht mal auf eine Konferenz.

Auf meiner allerersten Django-Con

habe ich halt Unistyle 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

von Volonteers

getragen wird und dann

die sich freuen, wenn da halt irgendeine Firma irgendwie

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

in letzter 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 Work ist 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 Extrathema,

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-Pattern irgendwie so ein bisschen eine Rolle spielte?

Ne, vielleicht habe ich das auch einfach falsch.

Einfach nur objektorientierte E-Mails quasi.

Genau, und 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.

Das macht Sendmail mit ein bisschen Fluff.

Genau.

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

Es gibt auch gerade eine große Diskussion,

weil bei Python da scheinbar etwas deprecated wurde.

In der letzten Version.

Und Django noch auf den alten Sachen.

Ich glaube, es wird nicht deprecated,

aber es gibt so 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 Anwendungsfrage, 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 bin 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's

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 dann 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 irgendwie abgekackt, hängen geblieben, mühsam. Dann habe ich irgendwann auf SCS 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 ein gutes Feedback bekommen, habe mich da 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 halt bis jetzt halt noch nicht so die richtigen Sachen hatte, es hat nie richtig funktioniert.

Da 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 centralisieren und da dann einfach meine Idee, also mit etwas kleinem Anliegen.

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.

Und ja, 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 gesagt hast, diese ganzen Features, Templates per HTML und so weiter, sehr gerne genutzt werden.

Tatsächlich ein Feature, was ich persönlich sehr mag, einfach so ein Convenience-Feature, de facto interessiert die wenigsten Leute wirklich der Plaintext-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 Plaintext-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 es halt niemand. Und ich habe mir mit einem externen Package, als Default rendert der einfach das HTML-Template als Plaintext 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 Plaintext 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 Testhelper 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, 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?

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, 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, also die E-Mails, die man schickt aus dem System, sollen ja irgendwie einheitlich sein. Wie auch bei einer Webseite hättest du ein Basis-Template. Du hast da das Logo oben drin, du hast da 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. Wenn man da einfach von der meiner Pony Express Basisklasse ableitet, eine eigene Basisklasse macht, dort dann halt die zum Beispiel die Get-Context-Data, 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 geprefixed sind oder zum Beispiel dann irgendwie meinwebshop.de minus 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 ich am Schluss dann, wo ich dann auch die N, die N-te,

dokumentieren muss, dass das wirklich dann meistens halt nur zwei oder drei Zeilen Code sind. Was es natürlich auch wieder sehr angenehm macht, neue E-Mails hinzuzufügen. Genau.

Cool, cool. 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-Repo, 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, die früheren Outlook-Versionen sind ja ziemlich wild, die dann unter der Haube so ein Indexbrowser 5 oder sowas haben, das tut dann schon weh, wenn man die unterstützen möchte, aber wie gesagt, kommt halt auch immer dann drauf an, wie wichtig das dann ist, also vielleicht akzeptiert, wie halt auch mit Browsern, vielleicht ist es 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, auf das ich mich gar nicht fokussiert habe, weil ich versucht habe, nicht zu viele Probleme in einem zu lösen. Ich habe selbst überlegt, ob ich diese Sache mit den Class-Based-E-Mails und die Sache mit der Testsuit, ob ich die auseinanderziehen soll, weil es ja im Endeffekt die Testsuit einen eigenständigen Nutzen hat, auch wenn ich keine Class-Based-E-Mails verwende.

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

Also hast du eh schon trotzdem mal Copy-Paste, musstest aber erst nicht bereitstellen mit dem Package, okay, verstehe.

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.

Genau, nicht im 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-Task-Manager.

Genau, auf jeden Fall dieses Django-Task-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, das ist nicht Django-Background-Task.

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 Optimalfall nicht meinen externen Thread blockieren, äh, meinen Main Thread blockieren.

Genau, deshalb gibt es in jedem Projekt, in dem ich gearbeitet habe, irgendeine Art von asynchronem Processing, meistens in der Form von Celery, das ist in der Python-Welt sehr bekannt, in der Django-Welt.

Sehr gehasst und gefürchtet.

Ja. Gibt es Django Q oder Q2? Ist jetzt aufgekommen, das ist so eine leichtgewichtigere Alternative, weil das Hauptproblem ist, dass Celery erzwingt, dass man irgendeinen Broker dazwischen stellt, der als Message-Queue dient.

Man kann das auch so konfigurieren, dass der direkt die Datenbank nimmt.

Oder der hat eine lokale Datei, in der er irgendwas reinschreiben kann und macht irgendeine SQLite noch extra auf.

Okay, das weiß ich, ja, aber ich glaube, man muss es nicht unbedingt, also es ist üblich, ja.

Und es ist auch, also ich habe das mehrfach schon gesucht und 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, dafür geht das, das ist relativ einfach, aber für den Broker selbst bin ich zumindest immer damit gescheitert.

Ich war 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 MariaDB 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.

und selbst bei ein paar tausend Tasks ist es immer noch

kein Problem. Vor allem, wenn man dann

vielleicht auch sagt, dass

die, dass die ein großer Task vielleicht auch eher

nachts läuft für irgendwelche Sachen,

dann, da ich auch keine Userlast habe

und das wird allgemein

sehr stark als Overkill angesehen. Dazu,

wie Dominik gerade schon gesagt hat, viele Leute fürchten

auf Celery für, aus verschiedenen

Gründen.

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

Aber vielleicht, also ist die Frage, ob es an Celery liegt oder

daran, dass Icing halt ein bisschen schwieriger ist?

Also da würde ich

gerne nochmal kurz eine Begriffsklärung machen, weil

viele sagen ja, Async,

und ich höre auch immer, wenn von

Async die Rede ist, dass dann Leute sagen so,

das merke ich

dann irgendwie nach einer gewissen Zeit, dass Leute eigentlich

sowas wie Celery meinen.

Aber das hat ja jetzt zum Beispiel mit

Async.io oder so

damit überhaupt gar nichts zu tun, das ist etwas ganz anderes.

Ja, also Celery ist ein eigener Worker-Prozess,

wenn ich mich nicht verstehe, der halt einfach Taster

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

und dann also diese Queue

leert. Ja, du hast so eine Anzahl von Workern

und du hast halt irgendwie

genau

ein Ding, das halt eventuell auf so einer

Queue drauf sitzt und dann verteilt es halt Jobs an

diese Worker und die machen dann halt

Dinge und schreiben ihre Resultate wieder

irgendwo hin.

Ich glaube, warum die Leute denken, dass es Essing ist,

weil das halt meistens, wie schon gesagt, nicht im

Main-Prozess läuft, obwohl man das auch machen kann. Du kannst ja

mit Django mitstarten oder so.

Die Frage ist auch da, was das halt heißt.

Also weil, Jochen weiß das

bestimmt besser, weil es ja irgendwie verschiedene Event-Queues

die man nutzen kann, G-Event oder Event

oder 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 der Django selber macht, dann muss man sich überlegen, welche

da benutzt wird. Ja, aber nichts, also

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

gar nicht. Also das ist einfach was ganz anderes.

Das ist auch nicht

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 anderen Prozesse hat, dann schon. Anders

geht es nicht.

okay. Also, genau.

Das 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, keine Ahnung,

also, nehmen wir an, du

stößt halt an einem Request,

also du hast halt irgendwie einen Button, da steht drauf, send email,

drückst du auf email

und wie soll das jetzt gehen, dass

dann eine email,

ja, so vielleicht geht es tatsächlich irgendwie,

aber das ist alles sehr hässlich, also

ne, du willst eigentlich

ein Task dafür schrauben, der ganz woanders ist.

Du hast recht, du willst das auf jeden Fall.

Da würde ich dir auf jeden Fall zustimmen.

Definitiv. Ja, 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 oder in einem anderen Thread, sondern es läuft in einem anderen Prozess. Also hat überhaupt gar nichts mehr mit dem Ding zu tun, mit dem der Interpreter da läuft.

Genau und insgesamt das Salary Setup ist halt auch relativ, also da schießt man wirklich schon mit sehr großen Kanonen, weil ja meistens man dann mehrere Worker hat, man hat einen Beat für Scheduling, also der im Endeffekt diesen Contab dann ersetzt, dann gibt es noch dieses Monitoring Tool Flower, was so mittelgut funktioniert und eher schlecht als recht meiner Meinung nach gewartet ist.

Nichtsdestotrotz, wenn man mal irgendwie reingucken möchte, hilft es schon. Dazu, das kommt halt noch, dass man wie gesagt meistens halt dann diesen Message Broker braucht, der halt dann meistens ein Redis oder ein RabbitMQ oder irgendein Derivat davon ist. Und das ist halt für viele Projekte, vor allem am Anfang, ist das halt ein enormer Setup-Aufwand. Wer das erste Mal in seinem Leben Celery einrichten muss, der wird daran keinen Spaß haben.

Nicht, weil, wenn du halt zum Beispiel auf das redest, wo du sonst nichts anderes benutzt oder sowas, das läuft halt halt die ganze Zeit rum.

Genau, und es bläht das Setup halt enorm auf und es ist jetzt halt, 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, da, ne, mit Celery kommen muss.

Wie gesagt, die Popularität von Django Q oder Q2, wie der Nachfolger davon heißt, 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, das wirklich in Django zu integrieren. Er hat erstmal ein Package gemacht, wie man das halt optimalerweise auch so macht, dass Leute es auch separat testen können. Und das Ganze hat er vorgestellt. Das war, ich weiß nicht, ob es wirklich eine Keynote war, aber es war auf jeden Fall de facto eine Keynote. Ich glaube, das war das, wo die Leute am meisten und am heißesten drauf waren.

Und das ist sehr spannend, weil ich tatsächlich auch bei mir in meinen diversen Projekten glaube ich auch einfach aktiv zurückbauen würde, weil ich einfach happy damit wäre und aus der Salary 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, macht das natürlich schon Sinn, da erst mal mit einer einfachen Lösung anzufangen, einer einfachen, soliden Lösung.

Billig und schnell rächt sich meistens irgendwann. Genau. Was übrigens auch ganz interessant war, ich habe der Talk von Carlton Gibson, ging im Endeffekt um mal wieder HTMX ist super und mit Alpine.js kann man zusammen coole Dinge machen 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 seltener geworden ist und in deutlich kleinere Mengen vergeben wird.

Und dass deshalb dieses, ich habe 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 irgendwie solide sein, aber es muss halt vor allem effizient sein. Und das hat deshalb nochmal den HTMX Tech verkauft, was ich persönlich auch absolut unterschreiben würde. Und das Interessante ist halt, dass ich zum Beispiel habe jetzt noch nie, ich meine, ich habe 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 es das auch nicht so.

Und es war immer für uns im Agenturbusiness, wir haben halt ein Budget und das ist eigentlich eher tendenziell zu klein als zu groß.

Ja, wie immer.

Und das ist einfach, das ist interessant, weil das, ja, ich meine, wird ihm vorher auch schon klar gewesen sein, 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 Referendums 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.

Klar, wenn man erstmal seine

komplette Applikation in HTMX ohne API gebaut hat

und man kommt ein und sagt, ich möchte das jetzt alles anders

haben, das ist natürlich auch nochmal teuer.

Also ich glaube, man muss da auch ein bisschen in die

also nicht nur sagen, wie viel Geld haben wir jetzt, sondern wo geht

das Ganze hin? 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.

Genau,

War echt super spannend.

Ich glaube,

dieses Django-Template-Partials kommt halt

auch irgendwie jetzt, ich weiß es rein,

ich weiß nicht, ob das schon bei 5.1 war,

oder doch eher 5.2, wahrscheinlich eher 5.2,

nehme ich mal an.

Oder hat er auch über

dieses Neapolitan-Ring

gesprochen, was er da...

Genau. Das ist ja auch so ein...

Neue Quad-Views oder so? Ja, genau.

Also das dreht sich alles um diese Idee

des Locality of

Behavior. Carlton Gibson hat jetzt

vor nicht allzu langer Zeit einen

Newsletter angefangen, Stack Report heißt

der, wo er einmal im Monat sehr

ausführlich zu einem Thema schreibt. Ich habe den

abonniert, das kostet glaube ich irgendwie 5 Euro

oder sowas. Bis jetzt hat es sich,

also ich glaube es gibt es erst seit 2 oder 3 Monaten,

bis jetzt hat es sich gelohnt, also ich mache da gerne

auch nochmal Werbung für ihn, unbezahlt.

Das finde ich echt cool.

Also es war echt interessant,

er hat jetzt über diverse Dinge da

geschrieben und das hat in dem aktuellen von diesem

Monat ging es halt um Locality of Behavior

und 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 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 fange jetzt schon mit, weiß ich nicht,

die, die, die an und mache das alles perfekt in

vielen Dateien, ein Neueinsteiger in dem Projekt

hat keine Chance zu verstehen, was eigentlich

passiert, sondern fangt erstmal klein an

und refactored, wenn ihr es wirklich braucht.

Weil viel von dem, ah ja, ich brauch das

nochmal, ich mach das mal irgendwie woanders hin,

kommt dann nachher mit, naja, ist doch

irgendwie anders geworden, war doch nicht so, wie ich es mir

gedacht habe. Und dann hat man halt immer diese doppelte

Refactoring-Schleife. Und dieses

Django Template Views ist halt die Idee,

Django Template Partials,

sorry, Partials,

dass man halt wirklich sagen kann, okay,

diesen Block kann ich jetzt mit HTMLX

neu rendern lassen, der ist aber trotzdem noch

in der großen Datei und ich muss es nicht zerpflücken,

wie man es halt vorher, also Stand jetzt mit

Vanilla Django macht

und diese Neapolitan

Crudviews ist auch die Idee, dass du halt wirklich mehr

Sachen an einer Stelle zusammen

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

ganzen, also GetPost und sonst wie Dinge,

die da passieren, halt alle drin sind.

Ich persönlich

finde, dass Locality of Behaviour ist, glaube ich,

eine gute Sache. Ich meine, das geht auch so ein bisschen nach

Yagni, also You Ain't Gonna Need It,

dass man halt nicht, dass man erstmal ü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,

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.

So ein bisschen so ein Trade-off 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.

Was dann auch gar nicht 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.

Das ist so, ja.

Oh, ich würde ganz kurz

nur einmal kurz einlaufen

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

es 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

Infrastrukturding 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 und dann hat man da Abhängigkeiten

inzwischen 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 heraussehlich realisiert werden

und dann geht es irgendwo zwischendurch schief und dann hast du halt

irgendwie so ein

explodiertes Gedärm irgendwie, was da rumliegt

und das ist halt so schön.

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 dem eigentlichen

Celery-Task 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. Ja.

Es gab da noch so ein tolles

Thread zu im Chaos Social,

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

der sehr, sehr interessant war.

Zu dem, ja. Einige coole Leute.

Unter anderem Carlton Gibson selber und

der Hüneck und so. Ja, Hüneck. Ja, genau.

Und diverse Leute. Da gab es ein Thread

zu, was braucht man jetzt bei Background-Tasks

eigentlich alles. Ja. Und was sind

da die Anforderungen genau?

Neu geschrieben oder anders implementiert.

Und auch alle haben sich über Celery beschwert aus Gründen.

Ja, ich kann das mal,

genau das Ding verlinke ich auch mal.

Ja, Fediverse ist halt zur Zeit, also wenn

er noch nicht ist, da sind halt

alle. 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 Twitter früher,

so ein bisschen Blümchenwiese mäßig.

Weil alle Leute sind,

oder viele der Leute, die man so kennt,

und da und man kann

sich mit denen einfach so unterhalten und so.

Ja, cool. Genau.

Ja,

das ist ein interessantes Thema.

Genau.

Was ich auch interessant fand,

ich habe mit auf der Konferenz

noch ein Wort mit dem

Creator da gewechselt

und er meinte auch, dass

früher wurde, also wenn ich es richtig

verstanden habe, ich will mir jetzt keine Worte in den Mund legen, aber wenn ich es

richtig verstanden habe, meinte er, dass früher bei Django

eher so die Idee war, alles was nach

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

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

Inkrement zu shippen, dass halt

stehen kann, das laufen kann

und alles, was halt danach kommt, einfach

zu gucken, wie reagieren die Leute,

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.

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 mal Terry, ja, es tut weh,

nimm's halt trotzdem, das ist das, was es

gibt.

Ja, und

wenn sich das jetzt ändert, dann ist auf jeden Fall

ein Pain-Point irgendwie auch weniger.

Die haben gesagt, dass wenn es

gut läuft, landet das in 5.2, du

weißt, wann 5.2 rauskommt, hattest du gesagt?

Äh, April hatte, ja.

Genau.

Dann wird dann neben meinem kleinen

Testhelper das zweite große Ding,

während du dann die Background hast.

Oh, sehr gut, sehr gut.

Ähm,

genau.

Ja, also, HTMX war diesmal auf der

JungleCon also auch quasi wieder so ein,

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

Genau. Ja, ich meine,

HTMX ist halt, ist halt

im Endeffekt die Silver Bullet, mit der

sehr, sehr viele Leute dann HTMX

vermeiden können,

was natürlich so ein bisschen

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

JavaScript braucht und das auch sehr viel 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 HTMX entschieden.

Auch mit einem Team, die tendenziell

eher JavaScript-Front-Endy

sind.

Ja, das ist natürlich interessant.

Und weil wir einfach auch gesagt haben,

das Projekt ist halt

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

das dafür halt HTMX 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 wirkte einfach nach dem

nach dem perfekten Hammer für diesen Nagel.

Was nicht heißt, dass wenn man

jetzt sagt, ich möchte jetzt 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, sag 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 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,

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

definitiv nicht als vernünftig funktionieren.

Ja, das hat nicht, 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,

da muss man dann halt JavaScript schreiben, das ist halt

so ein bisschen doof, aber

man kann halt irgendwie, das hält sich

dann halt in Grenzen. Also und

man weiß halt, also das habe ich

letztens wieder erlebt und das 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 das nicht so offensichtlich

und das ist einfach total

nervtötend, also

genau, das Problem hat man mit Web

Components halt auch nicht, weil das ist halt Standard

und wenn das jetzt funktioniert,

funktioniert das in

zehn 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

Was war das letzte? Django Slit?

Slippers.

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-Base-Klasse, also ein normales

Tailwind-Diff hat noch

10, 15 Klassen.

Das eskaliert ziemlich hart.

Ich finde es gut, aber

wie gesagt, es 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-Class und dann sieht jeder Button halt so aus, wenn ich

was überschreiben muss, bin ich halt arm dran,

dann wird es schwierig,

sondern dass man 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. 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 und 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 Komponentenlibraries, 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 rein

liest, 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 aussuchen.

Das ist alles nicht so kompliziert,

was einem gefällt.

Habt ihr mal schon mal herumgespielt mit dem

HTMX-Ding

für Mobile?

Das ist ja in dem 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

klingen will. Ja, klingen will. Ich habe es noch nicht,

nee, habe ich nicht angeguckt.

Also ich habe auch 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? Ne, also

das, 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, es ist halt,

Ich meine, für manche Sachen, wenn man

eh dafür ein Team hat und genug

Geld, dann kann man schon machen.

Ich würde das tatsächlich irgendwie mal ausprobieren.

Ich finde diesen Ansatz ganz cool.

Media für

für Mobile

auszuprobieren, das klingt irgendwie super.

Das ist derselbe Standard da und derselbe Prinzip.

Ist jetzt eigentlich, glaube ich, eine ganz

gute Überleitung zu dem nächsten Mini-Thema,

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 so Online-Konferenzen,

die jetzt am Ende des Tages

fünf bis zehn Leute einen

hart getimten fünf Minuten

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

Ja, und dann kannst du deine Ukulele mitbringen.

Ja, genau. Und ich finde,

dass wir haben jetzt das auch bei uns

intern in unserem, also bei

meiner Firma

bei den internen

Barcamps so gemacht, dass wir auch einen expliziten

Lightning-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 auch nicht existieren mögen. Aber so

Lightning-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 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 Vollkacke. 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 einmal vor ein paar Monaten, ich glaube im Februar diesen Jahres, haben wir eine komplette Lightning 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, also gerade in jedem Format,

also das irgendwie für Konferenzen oder Barcamp

oder was man auch immer hat, wo man zusammen arbeitet,

ist dieses Lightning Camp, äh,

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

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?

Über was?

Um den Fuß ins Wasser zu halten.

Über was soll der? Ach so.

Über Füße ins Wasser halt.

Nur über Füße und 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 Projektbeweis, 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

Product-Release-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

Testdatenbank aufgebaut wird, weil

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

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

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

sehr stark auseinanderziehen. Also wie man das

auch 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

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, fünf, sechs Jahren 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 einem Log, in so einer Historientabelle hinterlegt, da quasi noch die Änderungen anpasst. Das heißt, du kannst 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, 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 und eigentlich sollte man es tun, aber so richtig Lust hat da keiner drauf.

Ich weiß, da hat es schon mal drüber gefallen, dass sie irgendwie dann Migrations erinnert haben, dann bumm, oh, Daten-Migrate nicht.

Genau und ja, aus dem Grund fand ich das eigentlich für ein Lightning-Talk ein ganz cooles Thema, weil so war das den Leuten so, Leute, wenn ihr das Problem habt, guckt euch das an, das gibt's.

Ich habe dabei, als ich das Package gemacht habe, auch direkt noch eine zweite Sache gelernt. Es ist super, wenn man einen coolen Namen für sein Package hat. Man sollte aber vorher gucken, ob der vielleicht schon belegt ist, weil es gibt nämlich ein Django Zero Migration und Migration Zero ohne Django, glaube ich, bin ich ganz sicher.

Du hast es dann Zero Migration 2 genannt.

Django Migration Zero gab es tatsächlich

noch nicht. Aber es ist

natürlich trotzdem allein schon wegen SEO extrem

blöd, wenn halt dann Leute ständig aus falschem

Package kommen, weil das andere halt schon seit 2014

da rumsitzt mit einem Commit.

Genau, von daher, wenn jemand ein Package

erstellt, dann checkt vorher die Namen ab, das hilft.

Genau.

Jochen sollte das Package unbedingt mal benutzen.

Ich habe ja gestern nochmal über die Schultern geguckt, als du DjangoCast

migriert hast und irgendwie wie viele Migrations

da allein von weg herangekommen sind. Das waren ja hunderte.

Ich habe mir das auch überlegt, dass ich das überall

wegschmeißen möchte. Aber dann denke ich mir immer,

das sollte ich vielleicht dann machen, wenn sich an der Datenbank

nicht mehr so viel ändert.

Aber ich werde das auf jeden Fall

tun. Ich würde mich freuen, wenn du mein Package

ausprobieren würdest. Ja, kann ich mal

probieren, genau. Aber das Problem

ist auch bei mir, es ist halt

blöderweise eine Library und ich werde

Leuten... Bei der Library geht es eh nicht.

Da musst du ja mit

Squashen arbeiten.

Du weißt ja nicht, in welchem Stand

quasi, dass die letzte Person

dein Package

oder die Person dein Package nutzen?

Ja, vielleicht werde ich

bei irgendeiner Major-Version...

Release-Update und wer weiß,

wie viele Leute aus der Jochen sein Jochen-Paket

haben. Ja, kann sein, dass es nicht so viele sind.

Das ist schon richtig, genau.

Schieße ich nur in meinen Fuß

und nicht in den Fuß von noch 100 anderen Leuten.

Das kann ich vertreten.

Das Risiko von Open-Source-Hafen, ja genau.

Und man kann ja dann downgraden.

Datenbank brennt, sorry, Downgrader einfach.

Ja, ja, ja,

aber ja, das ist ein Problem.

Ich meine, das ist auch so ein Problem wie bei so Projekten

wie zum Beispiel Wagtail.

Da hat sich halt, es ist ja auch schon recht alt

und das ist halt auch, das verwendet man ja auch

als Library und da hat sich so viel Zeug

angesammelt, dass halt das mit dem Testen,

also wenn man jetzt quasi

und mein Paket hängt zum Beispiel auch von Wagtail ab,

deshalb muss ich für alle Tests

und so immer so Wege drumherum finden,

dass ich auf jeden Fall beim Testen nicht die

Migration laufen lassen

muss, weil sonst werden die Tests

irre langsam. Ah, dann machst du ReuseDB.

Ja. Und dann musst du halt dafür ganz hart sorgen,

dass alle Funktionen so wieder aufgeräumt werden.

Minus Minus ReuseDB, Minus Minus No Migrations, genau.

Aber dann gibt es halt dann so Fälle, wo

ah, nee, dann muss man es doch haben. Wie man zum Beispiel

wenn man dann halt vertroxt die ganzen

unterschiedlichen Versionen durchgeht,

dann muss man natürlich wenden, wenn man jetzt, dann kann man

nicht die gleiche Datenbank verwenden. Dann muss man halt schon

die Datenbank wieder wegschmeißen, wieder neu.

Es geht, aber es ist halt

es ist hacklich, ja.

Ja, ja. Ja, einzelne Pipeline.

Ja, du hattest ja gerade mich schon wegen Edinburgh gefragt, was ich sehr interessant fand jetzt in Vigo. In Edinburgh gab es von mehreren Leuten die, ich glaube auch berechtigte Kritik, dass die Themenauswahl zwischen, meistens kann man das ja grob in Community Talks oder Community Talks und Tech Talks mit vielleicht Meta Talks, die so irgendwie dazwischen sitzen, aufteilen und in Edinburgh war es relativ stark auf der Community Seite.

Also Leute, die über Community-Erfahrungen berichtet haben, wo Parallelen gezogen werden zwischen anderen Arten von Communities. Meine Erfahrung, wie ich das erste Mal zu Django Contributed habe, solche Geschichten. Das gab in Edinburgh von mehreren Leuten die Kritik, dass das halt relativ viel war und das ist mir positiv aufgefallen, dass ich fand, dass die Mischung aus den Community-Talks und aus den Tech-Talks und aus den Meta-Talks richtig gut war.

Und ich sehr, sehr happy war mit der Thema-Auswahl.

Ich meine, wie gesagt, es sind halt immer eine große Menge auch von Leuten,

die das mit Absicht zum ersten Mal machen,

die Englisch nicht als Muttersprache haben und sowas.

Das ist natürlich immer Sachen...

Ich habe immer gehört, dass Spanien immer so ein bisschen anstrengender ist,

was so das angeht.

Also für Englisch, weil halt da Englisch nicht so verbreitet ist

und viele Leute halt dann nicht so...

Ja, also wir hatten auch, glaube ich, gar nicht so viele Spanier.

Ich glaube, eine Frau aus Katalonien,

was so ein bisschen Definitionssache

aus Spanien ist oder nicht.

Und ansonsten,

ja, vielleicht ein, zwei, aber

wie gesagt, generell fand ich das

diesmal gut. Es war

sehr angenehm, waren viele interessante Sachen dabei.

Da gab es zum Beispiel einen

von Octopus Energy, das ist einer von den großen

Django-Playern, die auch eigentlich immer so mit Platinum-Sponsor

bei den Konferenzen sind, über

Layered Architecture bei Django. Ich bin schon sehr gespannt, wenn das

Video rauskommt. Das war sehr, also

bei YouTube werden die ja alle veröffentlicht.

Das war sehr, sehr viel

Informationen da drin und ich habe

mir nur ein ganz, ganz paar wenige Fotos gemacht

und ich bin sehr gespannt, mir das Ganze noch mal in Ruhe

zu Hause anzuhören.

Genau, wie geht die Background Workers,

die Sache von Carlton Gibson, es gab coole Meta-Talks.

Also

das fand ich von der Auswahl

her, bin ich da mit vielen schlauen Gedanken

nach Hause gegangen.

Und was ich auch

sehr interessant fand bezüglich des Community-Talks,

direkt die allererste Keynote

ging um Django Girls. Das ist

eine Vereinigung,

ein Non-Profit, glaube ich, inzwischen auch,

die dafür da ist,

explizit Frauen ans Programmieren

ranzuführen, weil es ja immer noch so ist,

dass halt die IT-Branche immer noch hart in Männerhand

ist und das soll einfach

vor allem die Mädels

so ein bisschen ermutigen, dass sie das können.

Also nicht irgendwie, ich glaube, da ist

gar nicht so groß der Faktor, dass du da rausgehst.

Also das ist immer so ein Wochenende-Workshop.

Positiv bestärken viele und so, genau.

Und der YouTube-Python ist auch, glaube ich, ein ganzer Workshop

für Tango Girls.

Und ich war, als das mal hier in Köln war, 2015 glaube ich, war ich auch mal da Coach und das war eine sehr interessante Erfahrung, hat echt Spaß gemacht und war auch interessant, weil die Mädels, da habe ich alle komplett noch nie irgendwas programmiert haben, also wirklich, die waren komplett bei Null, die drei, die in meiner Gruppe waren und wie die da auch unterschiedlich rangegangen sind, das war wirklich auch für mich, also im Sinne von, man hat ja auch immer wieder mal mit neuen Leuten zu tun, wenn mal jemand Neues anfängt, wenn man mal Werkstudenten betreut oder sowas, echt interessant zu sehen.

dieses Coaching

zu machen. Und wie gesagt, das ist halt

vor zehn Jahren, das war jetzt Jubiläum, in Berlin

gegründet worden, was ich auch ganz cool finde.

Also sprich, wenn

jemand jemand kennt, der

also jemand eine Frau

kennt, der die potenziellen

sowas Interesse hat, die werden immer wieder mal

hier und da angeboten, diese Workshops.

Und das ist glaube ich

echt cool, so für

den ersten Fuß ins Wasser

halten mal wieder. Und

die Idee dabei ist, dass die halt im Endeffekt

ihre erste Django-Seite erstellen

und auch irgendwo hindeployen. Und

der Fokus ist halt eher darauf, wie du schon gesagt hast,

positive Bestärkung, denn

ja, pädagogisch

wertvoll. Das Tutorial ist auch relativ

gut und relativ komplett.

Wenn man überhaupt mit Django ansteigen will.

Ich meine, das hätten wir jetzt vielleicht früher sagen müssen,

die Leute, die jetzt noch drin sind, sind wahrscheinlich

eher schon tiefer auch in Django, aber ja.

Vielleicht können wir das da weiter verraten auch.

Ja, aber das sind dann auch die Motivierten.

Bei denen lohnt sich das dann.

Ja, vielleicht tragen das in ihre eigenen

Communities weiter auf. Genau. Du kannst einfach

in der Linksammlung noch hinzufügen, da freuen die sich.

Ja, ja, mach ich auf jeden Fall.

Ich hab das auch tatsächlich an die Neulinge

bei uns mit Django, auch einmal Django Girls.

Also erst natürlich offizielles

Tutorial ist nicht schlecht, aber Django Girls auch so schönes

schnelles Einstiegsding.

Ich erinnere mich gerade, ich war jetzt zu langsam, um da

einzu... Ich hab mich dann irgendwann

kurz danach daran erinnert, es gab auch

jetzt irgendein...

Muss ich auch nachgucken, welcher das war.

Podcast-Episode Django Chat mit

einer von Octopus Energy

und die erzählte

da auch irgendwie, ja,

dass sie halt

auf so ein Problem

gestoßen hat, dass sie eigentlich nicht

wollen, dass in Templates irgendwie Datenbank

Queries passieren oder so. Und das

ist auch etwas, was mir inzwischen halt,

ich habe ja versucht, so ein bisschen Performance-Optimierung

zu machen, auch bei den