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.

Ich auch.

Dann fangen wir vielleicht mit ein bisschen News an und dann schlagen wir direkt ein, was

da noch los ist.

Jo, ich mache hier mal eine 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 dann gekommen?

Erst mal damit an

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

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.

Ging 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

DynamoCon hören und es gibt aber noch ein, zwei

andere News. Ja, genau.

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, schlagen sie jetzt voll ein oder doch nicht?

Was machen sie? Oh nein.

Jetzt haben sie sich für etwas anderes entschieden,

nämlich ihr Python-Team zu feuern.

Die haben da glaube ich direkt wieder ein neues eingestellt, ich glaube in Deutschland sogar.

Ja, sie sind jetzt, also es ist zu teuer mit dem teuren...

Die Amerikaner wollten alle 300.000 Dollar haben pro Jahr und haben sich irgendwann gedacht, das können wir in Deutschland auch viel heftiger haben.

Genau, dann gehen wir halt in so ein Billig-Lonand und dann in so eine, keine Ahnung, Billig-Vorstadt und zwar gehen sie nach München.

Und wollen da ein neues Team aufbauen.

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

Aber ich bin mal gespannt, ob das klappt, dass sie da jetzt irgendwie, keine Ahnung,

äquivalent rekrutieren können. Mal sehen.

Aber ja.

Ja, dann bestimmt er kann vor die guten Python-Leute sitzen.

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

Zudem gibt es keinen Lokal-Python-Rekrutismus hier auch.

Ja.

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

Das ist ja immer so, mehr Python-Leute einstellen und so, voll gut.

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

Vielleicht ist aber erstmal 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 Python 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 Reels bauen

für 3.13.

Ich habe es jetzt wieder, ich habe

heute echt keine Zeit gehabt, mich

die News nochmal anzugucken. Insofern tut mir

leid, wird etwas durcheinander, aber

ja, also genau. 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 1Password.

Also ich bin immer noch bei 1Password.

wie 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 ein 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?

für meine Werbung machen.

Also OneCupBot

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

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

kriegen würde. Das wäre sehr viel und das wäre

ein Riesenproblem, weil

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

Das ist natürlich praktisch.

Also es gibt noch mindestens fünf Jahre.

Ja, genau.

Dann tatsächlich

jetzt im Juni vor

zwei, drei Wochen

ist NumPy 2.0

erschienen nach irgendwie

14 Jahren

Entwicklungszeit.

Das war eine ganze Zeit lang

in Progress.

Und genau.

Ist vielleicht mal jetzt nicht der günstigste Moment

umzusteigen, sondern man sollte vielleicht

das jetzt mal auf kleiner 2 pinnen

oder mal gucken, bis alle anderen

sich angepasst haben, weil

das bricht halt einige

einige Geschichten.

Aber ja, schön, dass es jetzt raus ist

und dann macht einige

wie gesagt,

ich habe keine Ahnung, was alles genau

passiert ist oder ich wusste es mal, aber ich habe 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

und Jochen unterhalten sich über die Programmiersprache Python

erste 1.0 Release von Polos,

was ja auch vielleicht

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?

Nee, viel nutze ich das nicht. Ich nutze das ab und zu mal.

Hast du noch Pandas?

Ich nutze eher Pandas, weil ich mich halt da so an Pandas

gewöhnt habe. Nur weil du dich daran gewöhnt hast.

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

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.

Viele Sachen sind halt auch total komisch

und ich habe mich halt daran gewöhnt, zum Beispiel an diese

Multi-Index-Geschichten und so.

Wahrscheinlich ist das keine gute Idee

und es ist richtig, dass Polars das alles nicht

gemacht hat und auch selbst die Leute, die Pandas gebaut haben.

Das weiß man, McKinney sagt heute

im Podcast so, ja, das mit diesen ganzen

komplizierten Index-Geschichten und so, das war wahrscheinlich

und Jochen unterhalten sich über die Programmiersprache Python

PsychoPG 2 explizit

und wenn man jetzt aber normal PsychoPG nimmt,

dann ist es jetzt normal 3.

Ja, genau.

Und ja, super, da ist halt auch

so Async Support

jetzt mit drin und

diverse Geschichten.

Auf Postgres 15,

was ist das Minimum für PsychoPG?

Warte mal, lass mal grad gucken.

Bestimmt noch bei Tifa.

Wahrscheinlich, ich würde jetzt tippen, Postgres 12

oder so.

Minimove steht da nicht.

Nee, steht, steht, ich weiß es.

Keine Low-Hand-Food. 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 kontinuiert

sind,

oder

oder sie haben es konterinisiert

und haben dann vergessen, dass es irgendwie

was ist.

Aber ich sehe in der Praxis

ganz oft alte Daten machen.

Ja, stimmt.

Und ehrlich gesagt, ich finde es komisch, weil

das ist halt so, ich meine, das 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, Postgres 12 oder so, was ich häufig

sehe oder

wenn man jetzt stattdessen

einen Postgres 16 nimmt, dann ist es halt schon

Da hat sich schon einiges getan.

Da kriegt man irgendwie so 30%

Performance-Proofment einfach so gerade.

Also, ja.

Genau.

Ja, 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, es sind ein paar Sachen entfernt worden.

Also ein paar Extensions.

Die Websockers-Extension

ist nicht mehr drin. Oder ein paar Dinger.

Genau.

Ja.

Du benutzt es immer noch so gern?

Ich benutze es 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.

Man kann, aber ob das so viel Spaß macht, weil da ist ja manchmal vielleicht Echtzeit dann tatsächlich,

und Jochen unterhalten sich über die Programmiersprache Python

und Jochen unterhalten sich über die Programmiersprache Python

ohne sowas machen, aber kann sein, dass Chat

eine der wenigen Sachen ist, wo man das halt tatsächlich braucht.

Ja.

Und das ist mit Chat mit dem Server?

Chat mit dem Server?

Also keine Ahnung, du schießt mit dem Server

eine Frage und nicht einem anderen

Menschen.

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

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

das anzeigen,

das geht.

Genau.

Genau, das ist auch sowas.

Dafür braucht man

keine

direktionale Verbindung,

keine stehende Verbindung.

Okay, dann

5.1?

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

Ah, Query String, super. Das habe ich

hier halt schon ein paar Mal selber gebaut.

Warum gibt es das denn nicht?

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 ja jetzt möglicherweise

schon Sachen gesetzt und dann muss man das irgendwie,

ja, wie updatet man das hin?

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.

Nicht die großen Game-Changer, die sind jetzt eher

dann für 5.2, glaube ich, geplant.

Später mehr.

von eher Kleinigkeiten, die einem einfach helfen, besser und angenehmer zu arbeiten.

Ja, es gibt

Connection Pool Support für Postgres, was 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

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

Middleware to require authentication by default.

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 Dango konnte wahrscheinlich mehr erzählen,

als er aus dem 5.1.

Ich glaube, das ist so wahnsinnig...

Ja, genau.

Ist auch nichts Weltbewegendes mehr.

Alles klar, dann haben wir nur ein Event, das das gibt.

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 DjangoCon, lieber Ronny.

Also ich hab ja, 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 hab damals mit

1.4 angefangen, was

lange, lange her ist.

Damals hatten wir auch noch ein anderes Versionsgeschäft

und Jochen unterhalten sich über die Programmiersprache Python

zu halten. Das habe ich dieses Mal das erste Mal

gemacht. Das ist das erste Mal auf einer

echten Konferenzstage. 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 nicht schon ganz oft

live was erzählen hören. Ja, aber das

und Jochen unterhalten sich über die Programmiersprache Python

für Django gemacht habe. Das nennt sich

Django Pony Express.

Das löst im Endeffekt

das Problem, wer schon mal mit Django,

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,

und Jochen unterhalten sich über die Programmiersprache Python

und HTML-Templates

oder Inhalte hatten,

Plaintext-Part-Inhalte, Übersetzungen,

bestimmte Header, bestimmte Variablen,

die für das Base-Template benötigt werden,

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

sondern im Endeffekt wirklich nur drei oder vier Zeile

habe und die restlichen Sachen

an einer sinnvollen Stelle gekapselt sind.

Und ein zweites großes Problem, was mich

auch persönlich immer sehr gestört hat, ist,

dass E-Mails, weil die ja irgendwie so ein bisschen

eine externe API sind,

weil 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 die 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 Plaintext,

ob in den Context Parts da bestimmte Dinge

drin sind und so weiter.

Da habe ich einen Vortrag drüber gehalten,

das hat

sehr viel Spaß gemacht, ich war sehr nervös.

Ich kann sagen, du warst ja 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 wahrscheinlich 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, wer es noch nicht gemacht hat, geht mal auf eine Konferenz.

Auf meiner allerersten DjangoCon habe ich halt Uni-Styler 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,

und Jochen unterhalten sich über die Programmiersprache Python

Harnson 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 Worker

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

extra Thema, weil da haben wir vielleicht noch

zwei coole Links zu. Deswegen erzähl

gerne noch ein bisschen mehr zu deinem Talk über E-Mails.

auf die Backend.

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?

Oder...

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-level-Api, wenn man halt

wie gesagt, ein bisschen

aufwendigere E-Mails bauen möchte.

Das war Sendmail mit ein bisschen Fluff.

Genau.

Bei Sendmail selbst, das erstellt ein

Python E-Mail Objekt, glaube ich.

Es gibt auch gerade eine große Diskussion

bei Python, dass scheinbar etwas

deprecated wurde in der letzten Version

und Django noch auf den alten Sachen.

Ich glaube, es ist nicht deprecated, dabei gibt es etwas Neueres,

Cooleres und die Django-Sachen

unter der Haube benutzen auch die alten

und dann ist gerade viel in Bewegung bezüglich

E-Mails. Interessanterweise, ich bin da

ganz aus Versehen auf diesen Zug aufgesprungen.

Das ist direkt eine blöde

Anwendungsfrage. Wie verschickt ihr denn E-Mails?

Also tatsächlich,

das ist auch eine Frage, die ich

jedes Mal gestellt habe, wenn ich diesen Vortrag, ich muss

gestehen, ich habe den 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 einen Mailhawk 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 mein 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,

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 waren immer so mit den Bildern,

auch wenn man die runtergerechnet hat, waren immer so 500, 800 Kilo beide, 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 einen Euro oder zwei.

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 Core

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

dass da Sachen drin sind,

die meiner Meinung nach auch gut in 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, das 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 transitalisieren und da dann einfach meine Idee also mit etwas kleinem Anfang 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,

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 Forumsfeld 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 mal Leiner 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.

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 rüber 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 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

konsolenbasierten E-Mail-Programm noch

und Sitz. 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 auf 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, er macht auch sowas dann wie

Opt-Outlinks oder

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. Du hast, wie auch

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

Du hast das Logo oben drin, du hast

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

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.

und 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

nichts mit dem Pony Express zu tun,

aber 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

Ente

implementieren muss,

dass das wirklich dann meistens

halt nur zwei oder drei Zeilen Code sind.

Was es natürlich auch viele sehr angenehm macht,

neue E-Mails

hinzuzufügen.

Genau.

Cool, cool.

Hast du da so White Label Templates dabei, die quasi gar nichts

vorgeben, aber die es schon gibt, 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,

und Jochen unterhalten sich über die Programmiersprache Python

und Python-Browser. Vielleicht ist es auch einfach okay, wenn dann der eine, der halt noch den Explorer 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 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 genommen

ein Problem lösen, weil es 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

immer Copy-Paste, musst es aber erst nicht bereitstellen mit den Packages.

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

Genau, auf jeden Fall dieses Django-Tasks-Package,

das ist von Jack Howard, der hat das jetzt relativ schnell

zusammengenagelt, das ist echt erstaunlich.

Der freut sich auf jeden Fall über

dass du nicht Django Background hast

Ja, 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 noch einen Satz

sagen, was das überhaupt ist

Genau, die

also in den meisten Projekten

wenn man irgendwas asynchron machen möchte

da meine ich es gar nicht dieses

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,

ich muss ja mit der externen API kommunizieren,

um die E-Mail zu versenden, dann möchte ich ja im Optimalfall

nicht meinen externen Thread blockieren,

meinen Main Thread blockieren.

Und

genau, deshalb

gibt es in jedem

Projekt, in dem ich gearbeitet habe,

irgendeine Art von asynchronen

Processing, meistens in der Form von Celery.

Das ist in der Python-Welt sehr bekannt, in der Django-Welt sehr gehasst und gefürchtet.

Gibt es Django-Queue oder Queue-To?

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

Selbst bei ein paar tausend Tasks ist es immer noch

kein Problem. Vor allem, wenn man dann vielleicht

auch sagt, dass

der große Task vielleicht auch eher

nachts läuft für irgendwelche Sachen,

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 aus verschiedenen

Gründen.

Das ist dann auch kaputt eingestellt.

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

dass Async 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

geredet ist, dass dann Leute sagen so,

das merke ich dann

irgendwie nach einer gewissen Zeit, dass Leute eigentlich so etwas

wie Celery meinen, aber das

hat ja jetzt mit zum Beispiel

Async.io oder so, damit

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

Ja, also Tenor ist ein eigener Worker-Prozess,

natürlich, ich verstehe die halt einfach sehr

Tastacharbeit zu einer bestimmten Zeit, weil die halt in der Liste stehen

und dann also diese Queue leert.

Du hast eine Anzahl von Workern

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

Ja, und genau

Ich glaube, warum die Leute denken, dass es Async 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, aber 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 Django selber macht

dann muss man sich überlegen, welche da benutzt wird

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

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

und nehmen wir an, du stößt halt an in einem Request, also du hast halt irgendwie einen Button, das steht drauf Send E-Mail, drückst 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 du willst eigentlich einen Task dafür starten, der ganz woanders ist.

Du hast recht, du willst das auf jeden Fall, da würde ich 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,

also 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 es 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

zu tun, mit dem der Interpreter da läuft.

Also, ja.

Genau.

Genau, und insgesamt, das Celery-Setup ist halt auch

relativ, es ist halt, da schießt

man wirklich schon auf,

also mit sehr großen Kanonen, weil ja

meistens man dann mehrere Worker hat, man hat einen Beat,

der 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

kommt halt noch, dass man meistens

halt dann diesen Message Broker

braucht, der halt dann

meistens ein Redis oder ein RevitMQ

oder ein Derivat davon ist

und das ist halt für viele Projekte

vor allem am Anfang ist das halt enormer

Setup-Aufwand. Wer das

erste Mal in seinem Leben Celery

einrichten muss, der wird daran keinen Spaß

haben.

Wenn du halt zum Beispiel auf das Redis sonst nichts anderes benutzt

oder sowas, das läuft 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 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

und Jochen unterhalten sich über die Programmiersprache Python

interessant war. Ich habe

der Talk von Carlton Gibson

ging im Endeffekt um mal wieder

HTMLX ist super und mit AlpineJS 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 deutlich

in kleinere Mengen vergeben wird.

Und dass deshalb

dieses, ich habe ein Startup und ich möchte

irgendwas ausprobieren, dass die einfach mit viel

und Jochen unterhalten sich über die Programmiersprache Python

zu klein als zu groß.

Und 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

Reformen 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 mit HTMLX ohne API gebaut

und irgendwann kommt einer 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

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

rein. Ich weiß nicht, ob das schon bei 5.1 war oder doch eher 5.2, wahrscheinlich eher 5.2.

Oder hat er auch über

dieses Neapolitan-Ring gesprochen, was er da

das ist ja auch so ein... Neue Crud-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 so was.

Bis jetzt hat es sich, also

ich glaube, es gibt es erst seit 2-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 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

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 refactet, wenn ihr es wirklich braucht.

Weil viel von dem, ah ja, ich brauche es

nochmal, ich mache das mal irgendwie woanders hin,

kommt dann nachher mit, naja, ist doch

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

gedacht haben 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

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

Sachen an einer Stelle zusammen

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

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

Also so ein Trade-off mit KISS

oder sowas, 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, hilft das

fast am meisten, finde ich.

Was dann auch gar nicht schwer

zu verstehen macht, wenn das halt alles in einem Director liegt,

zum Beispiel, dann ist das schon vielleicht ein bisschen näher dran.

Aber wenn das Director in einem Gruß wird, dann ist das

wieder ein Problem.

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 es schon meistens, aber dann doch nicht

irgendwie so dauernd, 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

dazwischen und dann

und Leuten ist gar nicht so bewusst, dass es bedeutet,

ja, das geht jedes Mal über eine Prozessgrenze,

dann wird da irgendwie wieder irgendwas wieder realisiert,

dann muss der ganze Rahmen wieder so rausgelegt und realisiert werden,

dann geht es irgendwo zwischendurch schief

und dann hast du halt irgendwie so ein

explodiertes Gedärm irgendwie,

was dann rumliegt.

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 parken, sondern

von den Tasks, also in den eigentlichen

Celery-Tasks immer nur irgendwie Logik, die

irgendwo anders ist, aufrufen. Aber wenn du halt

im besten Logik verteilt über mehrere Tasks,

dann passieren scheröckliche

Dinge unter Umständen.

Absolut.

Genau, das war nur so ein kurzer Einwurf.

Es gab da noch

so ein tolles Thread zu

im Chaos Social,

den du auch den Link vorhin geteilt hast.

Das ist sehr, sehr interessant.

Einige coole Leute, unter anderem

Carlton Gibson selber und Hüneck und so.

Ja, Hüneck, genau. Und diverse Leute,

da gab es ein Thread zu,

was braucht man jetzt bei Background Tasks eigentlich alles?

Ja, genau. Und was sind da die Anforderungen

genau? Und das ist auch in der Praxis.

anders implementiert. Und auch alle haben sich über Celery

beschwert aus Gründen.

Ja, ich kann mir genau das Ding verlinken.

Ja, Fettyverse ist halt

zur Zeit, also wenn er noch nicht ist,

da sind halt alle...

Das steht tatsächlich auf meiner Liste und ich lese halt immer

so ein bisschen mit, aber naja.

Ja, also das fühlt sich an wie

Twitter früher, so ein bisschen

Blümchenwiese-mäßig, weil alle

Leute oder viele der Leute,

die man so kennt, sind da und

man kann sich mit denen einfach so

unterhalten und so.

Ja, cool.

und Jochen unterhalten sich über die Programmiersprache Python

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,

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 immer eine der Geschichten, die in Django

halt, ja, wo man da halt irgendwie dann

immer sagen musste, ja, nimm halt 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 Painpoint

irgendwie auch weniger.

Sie haben gesagt, dass wenn es gut läuft, landet das

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

wenn du dann die Background hast

Sehr gut, sehr gut

Genau

Ja, also

HTMLX 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 meine

HTMLX ist halt im Endeffekt die Silver Bullet mit der sehr sehr viele Leute dann HTMLX vermeiden k HTMLX JavaScript vermeiden k was nat so ein bisschen

Gänsefüßchen ist, aber 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 es jetzt tatsächlich bei dem letzten Projekt, das gestartet ist,

auch aktiv für HTMX entschieden.

Auch mit einem Team, die tendenziell

eher auf JavaScript-Front-End

sind.

Das ist ganz interessant.

Weil wir einfach auch gesagt haben,

Beglauers, da ist immer halt, dass das Projekt ist halt

so eine ganz klassische Backend-Ableck,

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 aber der Meinung, dass

man 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

perfekten Hammer für diesen

Nagel, was nicht heißt, dass

wenn man jetzt sagt, ich möchte es, 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, so mögliche 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 bin seit zwölf Jahren dabei,

das erste Mal, 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.

Also man kommt damit

erstaunlich, aber das hat nie wirklich gut

funktioniert.

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

weiß halt, das habe ich letztens

wieder erlebt und das tut jedes Mal weh,

größere Projekte,

die man lange nicht angefasst hat,

das ist immer schmerzhaft.

Also wenn man jetzt irgendwie

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 noch mal 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 und

genau, das Problem hat man mit Web Components

halt auch nicht, weil das ist halt Standard und

wenn das jetzt funktioniert,

funktioniert das in 10 Jahren

halt auch noch ganz genauso und

ja.

Tatsächlich haben wir jetzt in dem Projekt mal Django Components

ausprobiert, das ist ja auch eine von diesen vielen

ansetzen, da gibt es ja auch Django Slippers und wie die alle heißen,

um

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-Div hat noch 10, 15

Klassen,

so, 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 dieser Button halt so aus, wenn ich

ü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 HTML, Excel, Python, JS 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 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 aussuchen,

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

und dann Apps hat auf dem Telefon, die dann diese einzelnen Komponenten

halt mitziehen können, einfach von deinem normalen Endpunkt.

Klingwild.

Ich habe es noch nicht

angeguckt.

Also ich habe auch für

so mobile finde ich

eigentlich so die Webviews oder wie

heißen die noch? Progressive Web Apps.

Genau.

Ist eigentlich eine sehr schicke Geschichte.

Geht auf iOS auch deutlich mehr inzwischen als

früher. Wurden die nicht irgendwie gebannt?

Nee.

Apple hat da gedroht, aber das ist dann nicht

passiert.

Glücklicherweise.

hat doch ein bisschen zu viel

Gegenwind gegeben.

Und ich denke,

dass man vieles, was halt man

irgendwie vielleicht mit nativen

Apps früher gemacht hat, auch mit

Progressive Web Apps

hinbekommt.

Ansonsten sind halt die

Mobile-Geschichten halt immer so eine komplizierte

Geschichte, wenn man da wirklich eigene...

Ich meine, für manche Sachen, wenn man

eh dafür ein Team hat und genug

Geld, dann...

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

für diesen Ansatz ganz cool,

Hikar Media für

Mobile

auszuprobieren. Das klingt irgendwie super.

Das ist derselbe Standard da

und derselbe Prinzip.

Das ist 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

auch andere Konferenzen, die ist jetzt am Ende des Tages

fünf bis zehn Leute

einen hart getimten

fünf Minuten Maximalfortrag halten

können über irgendein Thema. Das heißt, die Vorbereitung

ist sehr gering bis nicht

vorhanden bei den Leuten.

Der coolste Vortrag, den ich

gehört habe, war Fuck it.

Zwei Minuten.

Die Idee dahinter ist einfach,

genau das, was du gerade gesagt hast. Ey, ich habe dann im Buch

dieses Kapitel gelesen, finde ich total spannend,

habe ich noch nicht ausprobiert, wollte ich 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, oder kannst du deine Ukulele mitbringen.

Ja, genau.

Und ich finde, wir haben jetzt das auch

bei uns intern,

in meiner Firma,

bei den

internen Barcamps so gemacht, dass wir

auch einen expliziten Lightning-Talk-Block 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 ein 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 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

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,

zusammenarbeitet, ist dieses Lightning Camp, äh, Lightning Camp, sag ich mal,

das 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 in 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, das dann doch ein bisschen länger wird.

Ja, das

nervt die meisten immer, glaube ich.

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.

Ach so, den Fuß ins Wasser zu halten.

Nein.

Nur Füße und Wasser.

Angeln mit den Fäden.

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

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 Kasten-Daten-Migration

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 wir den User.

Das heißt, man muss dann, wenn man

das macht, diese Migration

sehr stark auseinanderziehen.

Wie man das auch bei Circular Imports machen würde,

das ist ja generell das Python-Thema.

Und das ist sehr, sehr mühsam,

was dazu führt.

Und wie das halt dann immer so ist

mit Sachen, die mühsam sind.

Leute machen sie nicht. Umso einfacher Sachen sind,

umso schneller und umso besser werden sie getan.

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 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 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 sagst, 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. Eigentlich sollte man es tun, aber so richtig Lust hat

da keiner drauf.

Ich weiß, du hast mir schon mal drüber gefallen, dass wir irgendwie dann Migrations erinnert haben,

und Bum, oh, Datenbank 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 ihr mal 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 Django Cast

migriert hast und irgendwie wie viele Migrations

da dann 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 an der Datenbank aus der Datenbank zieht.

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

eine blöde Art 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 die letzte Person

dein Package,

die Person dein Package nutzen.

Ja, vielleicht werde ich

bei irgendeiner Major-Version...

Release-Update und wer weiß,

wie viele Leute außer Jochen sein Jochen-Paket sind.

Ja, ich kann sagen, dass es nicht so viele sind.

Das ist schon richtig.

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.

Man kann ja dann downgraden.

Datenbank brennt.

Sorry, downgrade einfach.

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

Also machst du reuse DB.

Und dann musst du halt dafür ganz hart sorgen, dass alle

Verschiebungen wieder aufgeräumt werden.

Minus minus no migrations, genau. Aber dann

gibt es halt dann so Fälle, wo

muss man es doch haben. Zum Beispiel

wenn man dann halt per Tox die ganzen

unterschiedlichen Versionen durchgeht, dann muss man natürlich

wenn man jetzt, dann kann man nicht die gleiche Datenbank

verwenden. Dann muss man halt schon die Datenbank wieder wegschmeißen.

Es ist

es geht, aber es ist halt, es ist hacklich.

Ja.

Ja, also in der 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 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 ist 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 happy war mit

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

Wir hatten auch, glaube ich, gar nicht so viele Spanier.

Ich glaube, eine Frau aus

aus Katalonien, was jetzt so ein bisschen

definitionsaristisch 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 Information da drin.

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

Genau.

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

für Tango Girls.

hier. 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, wie, 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.

Wenn jemand jemand kennt,

eine Frau kennt,

die potenziell sowas Interesse hat,

die werden immer wieder mal hier und da

angeboten, diese Workshops.

Und das ist, glaube ich, echt cool.

So für einen 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 hin deployen und der Fokus ist

eher darauf, wie du schon gesagt hast, positive

Bestärkung, denn

pädagogisch wertvoll.

Tutorial ist auch relativ gut

und relativ komplett.

Wenn man überhaupt in Django ansteigen will,

hätten wir es früher sagen müssen, die Leute, die jetzt noch drin sind,

sind wahrscheinlich eher schon tiefer auch in Django,

aber ja, das kann man weiter verraten.

Ja, aber das sind dann auch die

motivierten. Bei denen lohnt sich das dann.

Ja, vielleicht tragen das dann ihre eigene

Communitys weiter auf. Du kannst einfach

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

Ja, auf jeden Fall.

Ich habe das auch tatsächlich an die Neulinge

bei uns mit Dango, auch einmal Dango Girls.

Also er ist natürlich offizielles Tutorial,

ist nicht schlecht, aber Dango Girls auch so schönes

schnelles Einstiegsding.

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

einzu... Ich habe mich dann irgendwann

kurzer Nacht 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

Django-Cast-Dingen,

was ich baue, und

das ist mir auch ganz böse auf die Füße. Also

eigentlich, da dachte ich auch so,

oh ja, eigentlich möchte man nicht,

also wenn man in Templates Datenbank-Queries

macht, ganz blöde Idee, die sind dann

so weit gegangen zu sagen, sie benutzen

so eine Art Class-Based Views,

wo sie halt verhindern, also sie nehmen nicht die

Modelle, sondern sie machen irgendwie da so

Data-Class-mäßig irgendwie

Read-Only-Kopien von den Dingern,

sodass wenn du da irgendwo was versuchst

aus der Datenbank zu holen, dass das

halt einfach nicht geht.

Das kann ich gut verstehen.

das ist eine, also du willst eigentlich

wenn du zum Beispiel deine Daten

die Anzahl der Datenbankquerys in der Kontrolle behalten willst

willst du halt irgendeinen Punkt haben, wo du sagst

also hier, da sind alle Queries

und ich mache nirgendwo anders welche, weil

das ist so schwer

zu containen, wenn man

wenn da irgendwas passieren kann, dass das

halt ganz blöde Performance-

Implikationen hat. Und wo man dann quasi

durch das Frontend auch Angriffe machen kann oder was?

Ne, Angriffe, also es ist einfach

irgendwie, das ist halt

unheimlich

macht Dinge halt deutlich langsamer

und man weiß gar nicht so, warum

irgendwie.

Und ja,

also zum Beispiel...

Datenbank-Queries sind immer super langsam.

Ja, aber warum muss das, also wenn man die

eh machen muss, warum dann nicht im Template?

Also man muss ja eh drauf warten.

Naja, wenn man die halt an einer Stelle macht,

dann ist es halt auch nicht so schlimm.

Das weiß ich nicht so genau, das ist ein Gefühl.

Das habe ich noch nicht wirklich gemessen, aber ich habe auch das Gefühl,

dass wenn man die

Datenbank-Reels sehr verstreut macht,

dass das halt besonders schlecht ist auch.

Warum das genau ist, weiß ich nicht.

Was meinst du, was an verschiedenen

Stellen im Code meint er halt?

Oder an verschiedenen Orten des

Frameworks, glaube ich. Meinst du?

Ja, also wenn ich jetzt zum Beispiel gucke von

es kommt ein Request rein, ja, dann

passieren ja Dinge, Dinge, Dinge, Dinge, Dinge.

Auch erstaunlich viele, das weiß ich jetzt,

weil ich es halt so ein bisschen geproffelt habe.

Bei mir sind es halt von, also

wenn man jetzt einen Blog nimmt und da die

List-Page und dann halt nur so fünf Artikel

oder sonst irgendwas. Also aus diesem Listview

dann macht das halt so

110.000 Funktionsaufrufe oder sowas.

Was eine Menge ist. Ich dachte so, wow,

shit, warum ist das so viel?

Das ist ganz schön viel. Und mein Ding wäre jetzt,

wenn jetzt so alle tausend

Funktionsaufrufe kommt,

dann kommt irgendwie die Datenbank-Query. Das ist schlecht.

Also so war es quasi vorher

irgendwie implizit, weil

die Datenbank-Query ist halt da passiert, wo es

halt

aufgetreten ist. Und das war

und einfach nur dadurch, dass ich

und halt blockiert und dann muss man auf die Datenbank warten sondern auch dieses Ganze irgendwie ja man ist da in diesem Bereich wo dann Dinge die Jungle gebaut werden

oder ich weiß es nicht so genau, also das scheint alles nicht so

richtig kostenlos zu sein, sondern

das heißt, wann irgendwas geladen wird an der Stelle

und warst du irgendwie vorbereitet oder teardown

oder so hin und her, kostet dann unheimlich

viel, oder? Ja, also

ja, das allein, dass man da halt

irgendwie viele Objekte erzeugt und dann

ja, und wenn das halt

an einer Stelle ist, dann passiert das halt einmal

und wenn das halt verteilt ist, dann macht es das

irgendwie nochmal langsamer.

Und ja, ich versuche immer noch momentan gerade rauszukriegen,

woran liegt das eigentlich, dass da so viele Funktionsaufrufe

passieren, weil das ist einfach zu viel.

Kann man nicht eventuell,

also meine Idealvorstellung wäre natürlich,

dass ich irgendwann sozusagen

nur noch eine Datenbankquery mache oder so,

in der ich alle Informationen aus der Datenbank hole.

Geht das nicht vielleicht?

Ja, Tim, wie groß hättest du, wenn das

in RAM passt?

Ja, das ist alles gar kein Problem.

aber kann ich

so eine Query formulieren und wenn ich

jetzt die Daten aus dieser Query habe, kann ich die so transformieren

dass ich daraus wieder Django-Objekte machen kann

das ist halt so, das mache ich jetzt auch schon

also ich benutze nicht mehr

irgendwie einfach so, ich mache

aus

ich benutze nicht quasi

den ORM um halt Django-Modelle, sondern ich

ziehe die Daten halt in

einer Form, das ist auch sowas

wenn man cachen will, dann muss man das ja auch irgendwie

zum Beispiel als Sticked haben

dass man halt auch irgendwie serialisieren kann

Wenn du Django-Objekte hast, die kannst du nicht

also es gibt viele Dinge an Django-Objekten, die kannst du

nicht serialisieren.

Du kannst es auch nicht cachen, weil

Furry-Sets kannst du nicht gut cachen. Geht nicht.

Aber wenn du jetzt das in eine

Dict-Geschichte

überführt hast, wie im Prinzip

JSON serialisierbar ist, dann kannst du

halt auch das, was du aus der Datenbank kriegst, einfach

nehmen, irgendwie auf eine Platte schreiben oder so und sage

okay, die nächsten fünf Minuten einfach das Pfeil

nehmen und nicht mehr die Datenbank fragen. Oder

irgendwo in den Hauptspeicher oder in Redis oder sonst irgendwo hin.

und dann kannst du das halt cachen.

Aber das, genau.

Und aus den Dingern

Jungle-Modelle zu bauen, ist jetzt gar nicht so schlimm.

Da dachte ich auch so, das ist vielleicht schlimm.

Nö, ist gar nicht so schlimm. Ziemlich leicht.

Und ja, genau.

Also ja, ich mache momentan so ein bisschen Performance-Optimierungsgeschichten.

Ja.

Ja.

Ja, aber wenn Performance auch dazu führt,

dass du weniger Rechenleistung aufwenden musst, ist das ja sogar

Green Engineering.

Ja, ja.

Da gab es auch Vorträge dazu

110.000 Funktionsaufrufe für ein Webseitenrendering

ist nicht so richtig cool, ehrlich gesagt

das ist eher so mehr so braun

Aber Walter, ich habe gerade

deinen Einstiegspunkt vergessen

der mich daran erinnert hat, aber es war super interessant

bei diesem Dango Girls Vortrag gab es auch

so eine

ja so Success Stories einfach

von Mädels, die das halt teilgenommen haben

und die jetzt halt irgendwo einen coolen Job haben

oder irgendwie eine coole Erfahrung haben oder irgendwo

und Jochen unterhalten sich über die Programmiersprache Python

und Jochen unterhalten sich über die Programmiersprache Python

wo man dann irgendwie bis nachts um 12 irgendwie irgendwelche Marketing-One-Pattern zusammenlötet.

Nein, du hast völlig recht.

Ich glaube, das ist einer der Jobs, die von Hause aus sehr dafür geeignet sind,

dass man das remote machen kann und es relativ kompatibel ist zur Vereinbarkeit von Familie und Beruf.

Das ist eine echte Arbeit von zu Hause aus.

Eine Menge Geld verdienen.

Hier ist in die Halle angewogen.

Ich glaube, eine gesellschaftliche Transformation wäre sowas wie Vereinbarkeit.

eine der Hauptdinge.

Das fällt mir auch immer wieder auf.

Ja, das ist halt,

wenn irgendjemand den ganzen Tag irgendwo hinfahren muss

und dann mit Kinderbetreuung ist das schon schwer.

Ja, also ich meine auch

in den letzten Jahren

mit Kinderbetreuung, es passiert immer so viel

Zeugs, wo man dann,

das wäre übel gewesen, wenn ich

jetzt hätte in einem Büro sitzen müssen.

Oder hinfahren jeden Tag.

Du kannst auch nicht glücklich wegfahren.

Oder Schichtdienst einfach die ganze Nacht.

Ja, ganz übel.

Ja gut, aber es gibt Leute, die kriegen das trotzdem irgendwie hin.

Ja, das ist sehr beeindruckend.

Ja.

Ja, du wolltest jetzt über Party reden,

auch wenn wir gerade über Kinderkriegen reden.

Ja.

Für manche Leute ein Thema. Nach der Party kommt der Kater

und...

Nein, tatsächlich, bei den Dungercons

gibt es immer eine Party und

ich fand das ein ganz interessantes Thema,

weil in Edinburgh

war es so, dass man,

wenn man sich die Tickets kauft, musste man

ein Opt-in machen, ob man auf die Party

und Jochen unterhalten sich über die Programmiersprache Python

auf einmal alle nicht dahin gehen konnten, weil

sich eingeladen zur Praxis. Ach so.

Und weil einfach, weil halt

das Heck hier nicht gesetzt wurde und das war halt irgendwie

einfach so ein bisschen die Realität

zu Theorie. In der Theorie ist es kein Problem,

in der Praxis, naja, so ist es halt.