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

Schön, dass du wieder da bist.

Ja, Moderau.

Dann fangen wir vielleicht mit ein bisschen News an und dann schreiben

wir direkt ein, was du hast.

Kapitelmarke für News.

Okay, ähm.

Capitelmark hat nicht funktioniert.

Ah, toll.

Nichts funktioniert hier.

Das ist ja nichts Neues.

Ja.

Das sind keine News.

Schrecken wir erstmal 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.

Das ist ein sehr schöner Nationalpark, ein Inselnationalpark, direkt vor der Küste.

Wäre mal die Gelegenheit, dort hinzufahren, das sollte man

nicht verpassen.

Zeit wandern zu gehen eben.

Ist das so quasi da irgendwo diese Santiago de Compostela?

Ja, genau, das ist so ein bisschen südwestlich davon.

Also genau nördlich von Portugal.

Ah ja.

Und genau, ich hatte einen Tag Zeit, wandern zu gehen auf der Isla Cies, glaube ich.

Und das ist wirklich sehr zu empfehlen.

Klingt sehr gut.

Ja.

Ja, nächste Woche ist EuroPython, vielleicht das News.

Ich weiß nicht, ob man das noch hört, wenn ihr darüber mehr hört, vielleicht ist ja schon vorbei.

Ja, wahrscheinlich.

Ja.

Wir möchten gerne aber ein paar Themen von der Dunlockon hören.

Und es gibt aber noch ein, zwei andere News, die.

Ja, genau.

Also wir haben ja jetzt schon einige Zeit keine Sendung.

Das ist immer dasselbe Problem im Moment, aber gut.

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

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.

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

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

Ich glaube in Deutschland sogar.

Ja.

Sie wollen jetzt, sie sind jetzt was alles zu teuer mit den Teuerbauern.

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

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

Und zwar gehen sie nach München.

Und mal wollen da ein neues Zuckboard.

Da sind sie ja schon ein bisschen gewachsen, ja.

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

Mal sehen.

Aber ja.

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

Entschuldigung, ich wollte jetzt

keinen Lokalpatriotismus hier aufhören.

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

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

Und jetzt und welche, wo hat man das irgendwie so abrü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.

Das heißt, wenn man mal ausprobieren will, ob das eigene Zeug, was man so baut, irgendwie damit tut, dann kann man das jetzt mal machen.

Tut eigentlich, oder?

Ja, es gibt, glaube ich, jetzt auch.

Wo war das?

Irgendwas kann jetzt auch, man kann jetzt auf Wheels bauen für 313.

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.

Python 313 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 OnePasswort.

Also ich bin immer noch nicht, ich bin immer noch bei OnePasswort.

Mir tut das zwar etwas weh, dass das alles super teuer ist und so, aber ich finde es immer noch so der beste Passwort-Manager und der hat jetzt auch ein Python-API im Software Development Kit gekriegt.

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

Also sozusagen man kann halt Python-Sachen schreiben und dann fragt das Ding halt OnePasswort 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 würden, eigentlich hätten wir die Episodensponsor wegen.

Also OnePasswort 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 es gab 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.

Nee, ich wollte gerade sagen, noch im Kopf, ja.

Genau, was haben wir noch?

Achso, ja, es gibt auch gute Nachrichten, also das ist ja auch so ein Ding, da kriege ich mal 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 ein 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 per Sachen bei PIP installieren würde dann halt nicht mehr funktionieren.

Und die haben jetzt gerade auf der PyCon US verkündet, dass sie für fünf weitere Jahre PyPI sponsoren wollen.

Cool, cool.

Das ist natürlich praktisch.

Also gibt es Pyst noch mindestens fünf Jahre.

Ja.

Genau.

Dann tatsächlich jetzt im Juni vor gar nicht vor zwei, drei Wochen ist NumPy 2.0 erschienen, nach irgendwie, ich weiß nicht, 14 Jahren Entwicklungszeit oder was auch so.

Das war eine ganze Zeit lang in Progress.

Und genau.

Ist vielleicht jetzt nicht der günstigste Moment, umzusteigen, sondern man sollte vielleicht das erstmal 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 macht einige.

Wie gesagt, ich habe keine Ahnung, was alles genau passiert ist, oder ich wusste es mal, hab's wieder vergessen.

Ja, Performance ist irgendwie besser geworden.

Es sind ein paar API-Changes drin, das heißt, ihr müsst ein bisschen aufpassen, weil wenn ihr da irgendwie einfach updatet, dann kann es sein, dass solche 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 auch eh eine Semantic Version Ding, 2.0 Breaking API Changes, genau.

Genau, dann gibt es eine neue, also eine erste 1-0-Release von Pullers, was ja auch vielleicht ganz nett ist, dass man sich jetzt halt so drauf verlassen kann, dass die API-Daten 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.

Pandas oder ist das?

Ich nutze eher Pandas, weil ich mich halt da so an Pandas gewöhnt habe.

Ja, aber nur weil ich daran gewöhnt habe.

Aber bei Pandas haben die auch ein bisschen schneller gemacht.

Ich weiß gar nicht, gibt es irgendwie wirklich jemanden, der das mal getestet hat, was so für was besser geht.

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

Es gibt halt Dinge, die gehen mit Pullers 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 daran gewöhnt, zum Beispiel an diese Multi-Index-Geschichten und so.

Und wahrscheinlich ist es keine gute Idee und es ist richtig, dass Pullass das alles nicht gemacht hat und auch selbst die Leute, die Pandas gebaut haben.

Also das Basement McKinney sagt heute im Podcast so, ja, das mit diesen ganzen komplizierten Index-Geschichten und so, das war wahrscheinlich alles nicht so richtig.

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

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

Ja.

Genau, was gibt's noch?

Psycho PG 3.2 ist raus, also auch etwas, ich weiß nicht, ob alle schon umgestiegen sind auf 3.

Also ich habe das in wahrscheinlich.

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

Ja, genau, klar.

Ja.

Und ja, super, da ist halt auch so Essen Support jetzt mit drin und diverse Geschichten.

Also auf

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

Oh, das, warte mal, lass mal grad gucken.

Bestimmt noch bei einem Tiefer, oder?

Wahrscheinlich, wahrscheinlich.

Ich würde jetzt tippen, Postgres 12 oder so.

Minimum steht da nicht.

Nee, steht, steht, ich weiß, ich weiß nicht.

Keine Low Hamming Food.

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

Oder sie haben es kontinuierisiert und haben dann vergessen, dass es irgendwie.

Also, aber ich sehe in der Praxis, sehe ich ganz oft alte Datenbanken.

Ja, ja.

Stimmt.

Und ich ehrlich gesagt, ich finde es komisch, weil das ist halt so, ich meine, es kostet eigentlich ja nicht viel, das upzudaten oder da up-to-date 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 selbst, also bis wenn man jetzt stattdessen ein Postgres 16 nimmt, dann ist es halt schon, da hat sich schon einiges getan.

Also da kriegt man irgendwie so 30% Performance Movement einfach zum Gratis.

Also, ja.

Genau.

Ja, dann, oh, HTMX 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 und 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 ist, ja, es war echt total super.

Ich hatte irgendwie eine Menge.

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.

Man kann, aber ob das so viel Spaß macht, weil da ist ja manchmal vielleicht eine Echtzeit dann tatsächlich, wenn eine Echtzeit eine Reaktion hat, irgendwie interessant.

Wenn man jetzt polen würde, dann hast du immer so ein bisschen Latenz.

Server-Sent-Events, glaube ich, geht dann auch.

Ja, das geht dann 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 Loadbalanced man 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 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 keine mit ihm reden und denken alle, er stinkt irgendwie und niemand will mit ihm reden, hat tatsächlich 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.

Und was ist mit Chat mit dem Server?

Chat mit dem Server ist.

Also keine Ahnung, du schließlich mit Server eine Frage und nicht einem anderen Menschen.

Nee, da brauchst du es nicht.

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

Genau, da brauchst du es nicht.

Das geht.

Request-Response, super.

Dann wartest du einfach drauf.

Ja, also du kannst halt dann, du kannst ja auch das anzeigen, was dann zurückkommt, direkt.

Aber da brauchst du keine, da brauchst du keine stehende Verbindung.

So gechained jetzt, oder?

Ja, du kannst einfach Stream mal Daten.

Kannst du ja das anzeigen.

Das geht.

Genau.

Genau, das ist auch sowas.

Dafür braucht man das, da braucht man keine bidirektionale Verbindung oder keine stehende Verbindung, ja.

Okay, dann Django 5.1 hat es.

Django 5.1 Alpha erschienen, genau.

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

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

Es ist erst die erste Alpha.

Ja.

Also was ich hier schon sehe, ah, Query String, super, das habe ich ja halt schon ein paar Mal selber gebaut.

Aber warum gibt es das denn nicht?

Genau, man hat, also das Problem ist, wenn man quasi ein paar Dinge hinzufügen will 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 so schon Sachen gesetzt und dann muss man das irgendwie, ja, wie updatet man das hin?

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

Und das ist natürlich praktisch, genau.

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

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

Später mehr.

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

Middleware to require authentication by default, keine Ahnung, was das ist.

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

Ich glaube, da so wahnsinnig.

Ja, genau.

Ist auch nichts Weltbewegendes mehr.

Alles klar, dann haben wir nur erwähnt, dass es das gibt und dann.

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

Also ich habe ja du, also erstmal, du eigentlich müsst ihr ja von dir selber erzählen, weil du hast ja auch was gesagt, glaube ich, sogar, ne?

Genau.

Was Cooles erzählt.

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

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 dadurch die Möglichkeit, mich ja 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 Konferenzdate.

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

Das war sehr cool.

Das ist so eine Minikonferenz.

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

Und das war ein Tag und das war sehr nett, sehr familiär.

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

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

Ja, aber das war nicht mit Livestream zu.

Das ganze Internet konnte zugucken bei euren Livestreams bei Ambient während der ganzen Zeit, in der letzten Zeit, ja?

Ja, die Djungo Meters machen wir nicht.

Achso, das meinst du.

Ja, okay.

Fair enough.

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, wäre 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 50-Space-Template hat, die entsprechende Header gesetzt hat, die einen Unsubscribe-Link hat, die irgendwie ansprechend aussieht, etc.

Und da habe ich mir was überlegt, dass wer Django kennt, kennt der 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ürs 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 einen Drei- oder Vier Zeiler habe und die restlichen Sachen halt an einer sinnvollen Stelle gekapselt sind.

Und ein zweites großes Problem, was mich halt auch persönlich immer sehr gestört hat, ist, dass E-Mails, weil die ja irgendwie so ein bisschen eine externe API sind, weil das halt, ne, man schickt die irgendwie raus und die kommen dann quasi vielleicht wieder bei mir an, wenn ich es mir selber schicke, dass wir die nicht so richtig getestet haben, weil es einfach auch mühsam ist.

Und das Dango-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 Rapper 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 dann 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 Kontext-Parts da bestimmte Dinge drin sind und so weiter.

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

Ich war sehr nervös.

Ich wollte gerade sagen, was war 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.

Ich weiß es nicht.

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

Nichtsdestotrotz auch viel positives Feedback bekommen und ist auch tatsächlich nochmal eine ganz andere, 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 über wegen Corona.

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

Also ich finde, generell kann ich das jedem nur ans Herz legen, wer es noch nicht gemacht hat, geht mal auf eine Konferenz.

Auf meiner allerersten DjangoCon dachte, habe ich halt Uni-Style erwartet.

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

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

Aber die Vorträge sind auch wirklich gut.

Und wenn man denkt, dass das halt auch alles auf einem kleinen Budget läuft, da jetzt keine große Tech-Company dahinter steht, die da irgendwie Millionen einfach mal so verschenkt und dass alles irgendwie von Volunteers getragen wird und dann, die sich freuen, wenn da halt irgendeine Firma irgendwie einen Tausy reinwirft, ist das schon echt beeindruckend.

Und genau, da waren echt coole Sachen dabei.

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

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

Django Enhancement Proposal nehme ich.

Ah ja, genau.

Dieses Dab, 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 jetzt wieder recht populär.

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

Und diese Background-Walk 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 ein zwei coole Links zu.

Deswegen erzähl gerne noch ein bisschen mehr zu deinem Talk über E-Mails, bevor wir auf die Background-Text eingehen.

Okay.

Ja, genau.

Also die ja, was habe ich denn?

Was kann ich dazu noch sagen?

Irgendwie, weil das hat, war das nicht auch irgendwas mit einem, wo so ein Architekturdesign-Pattern irgendwie so ein bisschen eine Rolle spielte oder vielleicht habe ich das auch einfach falsch.

Einfach nur objektorientierte E-Mails quasi.

Genau, und es ist halt, es ist halt einfach ein Rapper 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.

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

Das gibt auch gerade eine große Diskussion, weil bei Python da scheinbar etwas deprecated wurde.

In einer letzten Version.

Und Django noch auf den alten Sachen.

Ich glaube, das hätte nicht deprecated, aber da gibt es irgendwas 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 Frage.

Wie verschickt ihr denn E-Mails?

Also tatsächlich, das ist auch eine Frage, die eigentlich jedes Mal gestellt wird, wenn ich diesen Vortrag, ich muss gestehen, ich habe ihn 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 an.

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 irgendein 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 man im Package versucht

zu lösen.

Wie macht ihr das?

Wir selbst nutzen SES.

Das ist von Amazon.

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

Ich glaube, Amazon hat ja viele von diesen Standards definiert.

Und das ist ein Service, der ist halt sehr günstig und sehr leistungsfähig.

Ich habe für ein Privatprojekt, ich engagiere mich da für Kinder in Bolivien, haben wir früher unsere 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, da 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 einen Euro oder zwei, ich weiß es nicht genau.

Und das läuft halt einfach.

Also du kannst dir mal eine bliebige 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 dir dazu sagen, was mich auch sehr gefreut hat.

Ich habe ja, wie gesagt, für den Vortrag auf der Corn 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, dass da Sachen drin sind, die meiner Meinung nach auch gut ins Django Core, also in das Framework passen würden.

Und dass wir dort, dass ich mich freuen würde, halt was zu contributen, aber ich habe bis jetzt halt noch nicht so die richtigen Sachen hat, es hat nie richtig funktioniert.

Habe ich ein paar Tipps bekommen, wie ich das mache.

Es gibt nämlich ein Django-Forum, das wird es auch gerade noch ein bisschen, die versuchen gerade so ein bisschen die Kommunikation da auch drin zu zentralisieren und da dann einfach meine Idee, also mit etwas Kleinem anfangen, zum Beispiel dieser Testing Helper, dass man halt quasi durch einem, also dass man alle textbasierten Medieninhalte einer E-Mail, also in den meisten Fällen HTML und Plantext, 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 Forums-Thread ausdiskutiert.

Die Lösung, da haben sich 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 leider gemacht hat.

Es gibt diesen schönen Spruch, weeks of programming can save hours of planning.

Das ist mal wieder sehr wahr.

Und genau, dann ist vor zwei Wochen, glaube ich, dann das auch gemerkt worden in Django Core.

Also in 5.2 habe ich meinen ersten Curmit, was mich sehr freut, jetzt nach zwölf Jahren.

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

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 du, wie du sagtest, diese ganzen Features, ne, Templates per HTML und so weiter.

Also 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 Witweb-basierten Clients denen 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 sitzt, 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 da hat man keine doppelten Templates mehr.

Und das ist natürlich schon ein Problem, dass man durch diese doppelten Inhalte, wie zum Beispiel bei uns in einem Projekt, wo wir gearbeitet haben, hatten wir bestimmt 50 verschiedene E-Mails, alles Mögliche, um halt den Kunden zu informieren, was so mit seinen Dingen passiert ist.

Und da wurde ständig vergessen, eine von beiden Teilen anzupassen.

Das kann man natürlich in gewissen Maßen durch diesen Test-Helper lösen, dass man das einfach unit-testet.

Nichtsdestotrotz, wenn es ein Rechtschreibfehler oder so 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 ja, löst das Problem damit.

Das ist sehr angenehm.

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, 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, dann halt gegeben, noch Kontextvariablen 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 eine, so ein, 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 Basistemplate.

Du hast da das Logo oben drin, du hast da vielleicht eine generelle Anrede, du hast einen Foot, wo ein paar legale Sachen drin stehen, wo vielleicht ein Unsubscribe-Link drin ist.

Und diese ganzen Sachen, die ganzen Informationen, die man dafür braucht, ist auch die dynamischen Sachen.

Zum Beispiel, man sagt, der Unsubscribe-Link enthält einen Hash oder sowas, dass der Nutzer identifiziert werden kann, der es draufgeklickt hat und solche Geschichten.

Wenn man da einfach von der Minor Pony Express Basisklasse ableitet, eine eigene Basisklasse macht, dort dann halt die zum Beispiel die GetContext Data, Weddango kennt, weißt du was ich meine, überschreibt, dann kann man da halt einmal die ganzen Sachen definieren.

Oder zum Beispiel, dass man einen Subject-Prefix hat.

Ich persönlich finde, es sieht immer schön professionell aus, wenn alle E-Mails, die vom System kommen, halt irgendwie geprefixt 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, ähm, ich meine, das ist halt ganz normale Objektorientierung, das hat jetzt nichts mit dem PonyExpress zu tun.

Aber das ist halt, das macht es sehr angenehm und führt auch dazu, dass die eigentlichen E-Mails, die mich dann am, die ich am Schluss dann, wo ich dann auch die N, die Ente, implementieren muss, dass das wirklich dann meistens halt nur 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 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 muss man ja unbedingt in die Show notes stellen.

Das ist super simpel.

Es tut es aber irgendwie.

Ich weiß auch nicht genau warum, wenn man sich halt da ein paar Regeln hält, je nachdem, wie alt die E-Mail-Clients man unterstützen möchte.

Die früheren Outlook-Versionen sind ja ja ziemlich wild, die dann unter der Haube so ein Intexplorer 5 oder sowas haben.

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

Aber wie gesagt, kommt halt auch immer dann darauf 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 Intex-Porter 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 Testsuite, ob ich die auseinanderziehen soll, weil es ja im Endeffekt die Test-Suiten 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 konnte immer Copy-Paste und musst du aber jetzt nicht bereitstellen mit den Package-Occupy Pastor.

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 sequentiell, oder?

Genau, nicht den Main Thread.

Und genau, die 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.

Das ist echt jemand.

Django Background Task, Django, ja, ja, Background Task Manager, ja,

ja, ja.

Genau, auf jeden Fall dieses Django Task-Package, das ist von Jake Howard, der hat das jetzt relativ schnell zusammengenagelt.

Das ist echt über echt erstaunlich.

Der freut sich auf jeden Fall über Dankes.

Das sind nicht Django Background Tasks.

Ja, ich merke schon, ich merke schon, ich google hier noch den Fall.

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 es überhaupt ist.

Genau.

Also in den meisten Projekten, wenn man irgendwas asynchron machen möchte, da meine ich jetzt gar nicht dieses Ingänze 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 eine, 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, äh, mein Main-Thread blockieren.

Und genau, deshalb gibt es in jedem Projekt, in dem ich gearbeitet habe, irgendeine Art von asynchronem Processing, meistens in der Form von Salary.

Das ist in der Python-Welt sehr bekannt.

In der Django Welt.

Sehr gefasst und gefürchtet.

Ja.

Gibt es Django Q oder Q2, ist jetzt aufgekommen, das ist so eine leichtgewichtigere Alternative, weil das Hauptproblem ist, dass Salary erzwingt, dass man irgendeinem Broker dazwischen stellt, der als Message Q dient.

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

Oder der hat eine lokale Dateiendessung, was reinschreiben kann, dann macht irgendein 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, ich habe das mehrfach schon gesucht und für die Result-Backends, also bei Salary, wenn quasi um die Ergebnisse zu speichern und dass im Endeffekt so eine Art Lok, was passiert ist.

Dafür geht das, es ist relativ einfach, aber für den Broker selbst bin ich zumindest immer damit gescheitert.

Ich habe 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 Maria DP hat.

Die kann in den, zum Beispiel bei uns, in den meisten Fällen, kann die paar hundert Tags 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 dir ein großer Task-Feld 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 Salary aus verschiedenen Gründen.

Die ist dann oft

kaputt auch eingestellt, verhält sich komisch.

Aber vielleicht ist die Frage, ob es an Salary liegt oder daran, dass Async halt ein bisschen schwieriger ist.

Nee, also da würde ich gerne nochmal kurz eine Begriffsklärung machen, weil viele sagen ja, Async, ja, und ich höre auch immer, wenn von Async die Rede ist, dass dann Leute sagen, so, das merke ich dann irgendwie nach einer gewissen Zeit, dass Leute eigentlich sowas wie Salary meinen.

Aber das hat ja jetzt mit zum Beispiel mit Async.io oder so, damit überhaupt gar nichts zu tun.

Das ist was

ganz anderes.

Ja, also Salary ist ein eigener Worker-Prozess, wenn ich verstehe, der halt einfach Tasterarbeitet zu einer bestimmten Zeit, weil die halt in der Liste stehen und da also diese Que leert.

Ja, du hast so eine Anzahl von Workern und du hast halt irgendwie genau ein Ding, das halt eventuell auf so einer Que 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 das Async ist, weil das halt meistens, wie schon gleich gesagt, nicht im Main-Prozess läuft, obwohl man das auch machen kann.

Du kannst ja mit Django mitstar oder so.

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

Also weil Jochen weiß das bestimmt besser, aber es gibt ja irgendwie verschiedene Event-Ques, 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 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, und wenn man die hat, genau, wenn man die anderen Prozesse hat, dann schon.

Anders geht es nicht.

Okay.

Also, genau.

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, in dem Regel, also nehme mal an, du stößt halt an in einem Request, also du hast halt irgendwie einen Button, da 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, ganz

woanders hast du.

Du hast recht, du willst das auf jeden Fall.

Da würde ich dir auf jeden Fall zustimmen, aber ich glaube, das ist unbedingt definitiv.

Ja, also aber diese beiden Dinge haben eigentlich nichts miteinander zu tun.

Auch wenn das eine für das andere vielleicht so halb irgendwie verwenden kann, aber nee, das ist eigentlich was ganz anderes.

Wie gesagt, es ist halt, es ist halt, also die, wenn du dir, wenn du quasi auf den Main-Thread schaust, dann läuft es halt irgendwie nicht da drin.

Von daher liegt es halt nahe, das irgendwie asynchron zu nennen.

Auch wenn das mit dem Async, mit dem Python-Async natürlich nichts zu tun hat, technisch.

Ja.

Genau, aber es läuft halt nicht irgendwie Async, sondern oder in einem anderen Thread, sondern es läuft in einem anderen Prozess.

Also hat überhaupt gar nichts mehr mit dem Ding zu tun, mit dem da Interpreter da läuft.

Also, ja.

Genau, und insgesamt das Salary-Setup ist halt auch relativ, also es ist halt da, 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 Crontub 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, 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 enormer, ist das ein normaler Setup-Aufwand.

Wer das erste Mal in seinem Leben Salary einrichten muss, der wird daran keinen Spaß haben.

Ich weiß, weil auch 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 so wie.

Genau.

Und es blätter das Setup halt enorm auf und es ist jetzt halt seit seit scheinbar auch Jahren ist es halt irgendwie allen bewusst, dass es halt schon cool wäre, wenn Django da selber was könnte, um man halt eben nicht mit da, ne, mit Salary kommen muss.

Wie gesagt, die Popularität von Django Q oder Q2, wie das wieder 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, hat es 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, was die Leute, 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 auf das 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.

Es macht natürlich Sinn, das Explizites zu haben.

Nur wie immer, es macht halt, vor allem, wenn man jetzt auf ein Budget achtet, macht es natürlich schon Sinn, da erstmal 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 hab 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 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 dass es halt nicht so, wir bauen es die in der perfekten Welt, sondern es muss schnell gehen, es muss irgendwie solide sein, aber es muss halt vor allem effizient sein.

Und dass er deshalb nochmal ein HTMX-Tag verkauft hat, 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 View, kannst du ausgefallene Reference 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 USB daran.

Klar, wenn man erstmal seine komplette Applikation in HTMX ohne API gebaut hat, irgendwann kommt einer und sagt, ich möchte das alles anders haben, das ist natürlich auch nochmal teuer.

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

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 Kalten Gibson halt immer so ist.

Genau, war echt, echt super spannend.

Ich glaube, dieses Django Template Partials kommt halt auch irgendwie jetzt, ich weiß, rein.

Ich weiß nicht, ob das schon mal 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.

Kalten gibt es dann jetzt vor nicht allzu lange 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 fünf Euro oder sowas.

Bis jetzt hat es sich, also ich glaube, jetzt gibt es erst seit drei Monaten, bis jetzt hat sich es gelohnt, dass 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 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 mache, ich fange jetzt schon mit, weiß ich nicht, DDD an und mache das alles perfekt in vielen Dateien.

Ein Neuansteiger in einem Projekt hat keine Ahnung, keine Chance zu verstehen, was eigentlich passiert, sondern fangt erstmal klein an und refactoret, wenn es wirklich braucht.

Weil viel von dem, ah ja, ich brauche es 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 Tango Django Template Views ist halt die Idee, äh,

dieses Django Template Partials,

Partials, sorry, Partials, dass man halt wirklich sagen kann, okay, diesen Block kann ich jetzt mit HTMX neu rendern lassen.

Der ist aber trotzdem noch in der großen Datei und ich muss es nicht zerpflücken, wie man 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 ganzen, also Getposts und sonst die Dinge, die da passieren, halt alle drin sind.

Ich persönlich finde, dass Locality of Behavior 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 engineieren und ich glaube, dass dich im Kopf zu behalten, so muss ich das jetzt wirklich tun?

Also ein bisschen so ein Trade-Off mit KISS oder sowas 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 drin stehen, das heißt, wenn das irgendwie am Anfang überblicklich ist, wird es halt auch dann wieder hässlich.

Und wenn da 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 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 man da, dass die, dass viele, 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 Celeries ist dann halt auch sehr einfach.

Und dann, weil man da Abhängigkeiten zwischen und dann und Leuten ist gar nicht so bewusst, dass es bedeutet, ja, dass es geht jedes Mal über eine Prozessgrenze, dann wird da irgendwie wieder so irgendwas wieder realisiert, dann muss der ganze Kram wieder so hauptsächlich realisiert werden.

Und dann geht es irgendwo zwischendurch schief und dann hast du halt irgendwie so ein explodiertes Gedarm 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 Salary-Task eigentlich nur, okay, man ruft halt dieses Ding auf, fertig.

Wie man auch im Video schreiben würde.

Möglichst schlank und eigentlich nur die Dinge komponieren, denn wirklich da implementieren.

Und keine Logik in die Tasks parken, sondern die von den Tasks, also in dem eigentlichen Salary-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 scharöckliche Dinge oder Umständen und ja.

Absolut.

Genau, das war nur so ein kurzer Einwurf.

Es gab da noch so ein tolles Thread zu im Carlos Sochel, den du auch den, wo du den Link vorhin geteilt hattest, der sehr interessant war.

Einige coole Leute, unter anderem Carlton Gibson selber und der Hönick und so.

Ja, genau.

Und diverse Leute dagegen gab es einen Thread zu, was braucht man jetzt bei Background-Tasks eigentlich alles.

Und was sind da die Anforderungen genau und was sind die Bildung?

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

Ja, ich kann das mal, ich kann, ja genau, das Ding verlinke ich auch mal.

Ja, Fediverse ist halt zurzeit, also wenn er noch nicht ist, da sind halt alle.

Das geht tatsächlich auf meiner Liste.

Ich lese halt immer so ein bisschen mit, aber naja.

Ja, also da ist, also das fühlt sich an wie so Twitter früher, so ein bisschen Blümchenwiesemäßig.

Weil alle Leute sind, oder viele, viele der Leute, die man so

kennt, sind da, Kleistranzen.

Und man kann sich mit denen einfach so unterhalten und so.

Ja, cool.

Genau.

Ja, ist ein interessantes Thema.

Genau.

Und ich bin, 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 im 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 erstmal mit was anfangen, was halt alleine steht, also dieser MVP-Gedanke.

Und natürlich kann man noch 400 Sachen nach und dazu bauen, aber braucht man die wirklich?

Will das die Crowd so?

Und dass die jetzt wirklich anfangen und versuchen, ja, also wirklich mit einem kleinen Inkrement zu shippen, dass das halt stehen kann, das laufen kann und alles, was halt danach kommt, einfach zu gucken, wie reagieren die Leute.

So, was für Sachen werden wirklich angefragt.

Das finde ich halt sehr interessant, weil ich glaube, das ist einfach so ein generelles Ding.

Wenn man irgendwie in der Softwareentwicklung ist, dieser MVP-Gedanke ist so, so, so zentral.

Und da kann man so viel falsch machen und so viel Geld und Projekte und Chaos verlieren, wenn man halt nicht dem MVP denkt.

Weil schöner geht halt immer und ja, genau.

Ja, und genau, bei Ruby on Rails ist halt auch diese Background-Horse-Geschichte schon seit Ewigkeiten drin.

Und das war halt mal eine der Geschichten, die in Django halt, ja, wo man da halt irgendwie dann immer sagen musste, ja, nimm halt Terry.

Ja, es tut weh, nimm es halt trotzdem.

Das, was es gibt.

Ja.

Und wenn sich das jetzt ändert, dann ist auf jeden Fall ein Pain point irgendwie auch weniger sehr gut.

Also die haben gesagt, dass wenn es gut läuft, landet das mit 5.2.

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

April hatte, ja.

Genau.

Dann wird dann neben meinem kleinen Testhelper das zweite große Ding, wenn dann die Background has.

Sehr gut, sehr gut.

Genau.

Ja, also HTMX war diesmal auf der Djungle Korn also auch quasi wieder so ein.

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

HTMX JavaScript vermeiden können, sorry.

Was natürlich so ein bisschen ein Gänsefüßchen ist, aber natürlich immer noch ein bisschen JavaScript braucht und das auch sehr 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?

Und 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 auf JavaScript-Front-endy sind.

Oh, das ist interessant.

Und weil wir einfach auch gesagt haben, wir glauben, dass das Projekt ist halt, das ist eine ganz klassische Backend-Applick.

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, dass dafür halt HTMX wirklich gut funktioniert, weil das ist das, was Django wirklich gut kann.

Und das Projekt wird, ist es auch nicht etwas, wo man sagt, das ist jetzt irgendwie, wenn die Firma durch die Decke geht, dann so und so, sondern das wird immer eine Backend-Applikation bleiben.

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

Aber das wirkt einfach nach dem perfekten Hammer für diesen Nagel.

Was nicht heißt, dass wenn man jetzt sagt, ich möchte 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 dann 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, wenn 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 ganz Füßen sehen muss, React und Bio sind ja auch keine Front-end 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.

Ja, ja, klar.

Nichtsdestotrotz wird das natürlich hart gefeiert in der Community, weil wie das auch bei mir so ist, das ist es halt, ich meine, wie gesagt, ich bin seit zwölf Jahren dabei, das erste Mal, dass man, dass ich jetzt wirklich ein Werkzeug bekomme, das vernünftig funktioniert.

Und das, was man früher so mal gemacht hat, wie jQuery und sowas, definiere ich definitiv nicht als vernünftig funktionieren.

Ja, das hat nicht.

Also ging, also man konnte man da schon nicht, 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 Webcomponents.

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 ist, 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 beim View-Projekt, ist es 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 nicht so offensichtlich.

Und das ist einfach total nervtötend.

Also, und genau, das Problem hat man mit Web Components halt auch nicht, weil das ist halt Standard und das, wenn das jetzt funktioniert, funktioniert das in zehn Jahren halt auch noch ganz genauso und ja.

Tatsächlich haben wir jetzt dem Projekt mal Django Components ausprobiert, das ist ja auch eine von diesen vielen Ansätzen, da gibt es ja auch Django Slippers und wie die alle heißen,

um das letzte Django Slip 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 Konvention mit Tailwind, die ja dann eher diese Utility-Based-Klasse, also ein normales Tailwind-Div 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 Bootstrip 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 halt wirklich die Sachen individuell mit diesen Klassen halt definieren kann, ohne halt die ganze CSS-Magie da hinter 100% verstehen zu müssen.

Und da diese Komponenten in der Djungle Welt zu machen, klingt super interessant.

Das konnte man vorher auch schon mit Includes machen.

Ja, genau, mit Includes, ja.

Es gibt auch eine neue Version von Includes irgendwie, die das so ein bisschen zwischenspeichern können, irgendwie auch.

Ja, auf jeden Fall, da gibt es Packages, die expliziter 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 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, L PanJS und dann irgendwas an diesen Komponentenlibraries, die sich gerade, die emergieren gerade alles.

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 im Endeffekt auch irgendwas aussuchen.

Das ist alles nicht so kompliziert, was einem gefällt.

Habt ihr immer schon mal herumgespielt mit dem HTMX-Ding für Mobile?

Also in einem Hyper Media 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,

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

Klingt.

Klingt will, ich hab's noch nicht, nee, nicht angeguckt.

Also ich habe auch für so Mobile, finde ich, eigentlich sind die Webviews oder wie haben die nach, wie heißen die noch?

Progressive Web Apps, genau.

Ist eigentlich eine sehr, sehr schicke Geschichte.

Da geht auf iOS auch deutlich mehr inzwischen als früher.

Wurden die nicht irgendwie gebannt?

Nee.

Also das, ah ja, Apple hat da gedroht, aber das ist dann nicht passiert.

Glücklicherweise 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 Progressive Web-Apps hinbekommt.

Und ansonsten sind halt die Mobile-Geschichten halt immer so eine komplizierte Geschichte, wenn man da wirklich eigene für manche Sachen, wenn man, wenn man eh dafür ein Team hat und genug Geld, dann ja, das ist ein bisschen.

Ich mache das tatsächlich irgendwie mal ausprobieren.

Ich finde diesen Ansatz ganz cool, halt Par-Media für Mobile auszuprobieren.

Das klingt irgendwie super.

Und das ist der selbe Standard da und dasselbe Prinzip.

Es ist eigentlich, glaube ich, eine ganz gute Überleitung zu dem nächsten Mini-Thema, nämlich Lightning Talks.

Wer es nicht kennt, die Lightning Talks ist in ihr, das ist bei den Django Cons zumindest.

Ich war noch auf keiner anderen Konferenz, aber ich glaube, es gibt auch an anderen Konferenzen.

Die ist, dass am Ende des Tages, fünf bis zehn Leute einen hart getimten fünf Minuten Maximalvortrag halten könnte bei irgendeinem Thema.

Das heißt, die Vorbereitung ist sehr gering bis nicht vorhanden bei den Leuten.

Aber das war sehr 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 ein Buch, dieses Kapitel gelesen, finde ich total spannend, habe ich noch nicht ausprobiert, wollte ich euch mal mitgeben.

Oder was ich vorhin gemacht habe, ey, es gibt ja noch Components, wer sich dafür interessiert, schau euch 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.

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-Block haben, weil viel von so Content-Teilen und Wissensmanagement scheitert halt daran, dass die Leute sich wirklich aufrauffen 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 einen Lightning Talk gibt es das halt nicht.

Du stellst dich da hin oder in dem Fall jetzt in der Post-Corona-Nuen Moderne, du sitzt dann hinter deiner Webcam und teilst dann halt kurz dein Browser oder deine zwei Slides und sagst, Leute, das habe ich gesehen, das habe ich gelernt, voll gut oder auch voll kacke.

Und das ist ein echt cooles Format, dem man auch, wie gesagt, gut, glaube ich, in Firmen oder auf Meetups auch sehr gut.

Wir haben mal einmal vor ein paar Monaten eine, 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 bin auch, also gerade in Nebenformat, also das irgendwie für Konferenz oder Barcamp oder was man auch immer hat, wo man zusammenarbeitet, ist dieses Lightning Camp, oder Lightning Camp sage ich schon, 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 irgendwelche Sessions auf Dingen, so kurze Slots, selbst wenn es nur eine Viertelstunde ist, zwei Minuten und 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 wenn 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 zufür, ob man selber mal einen Vortrag halten möchte.

Eigentlich habe ich ja gesagt, das war echt eine richtig coole Erfahrung.

Und ich habe auf der letzten Konferenz in Edinburgh 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?

Über was?

Um den Fuß ins Wasser zu halten.

Über was

für der Auto.

Ach so.

Fuß ins Wasser halten.

So keinen Satz möglich.

Nein.

Nur über Füße und Wasser.

So wie schon erhalten.

Angeln mit den Szenen.

Das war die Frage.

Ich habe tatsächlich keine Ahnung.

Ich habe dieses Jahr einen über mein Django Migration Zero Package gehalten.

Ich beantworte meine Frage aber auch 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 beweist, da sammeln sich ziemlich viele Migrations nach kürzester Zeit an.

Diese Migrations, wenn man die volle Kontrolle über Daten, über die 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 Machen des Creators.

Aber in so einer klassischen Applikation, die man baut, hat man eigentlich die volle Kontrolle über die Datenbanken.

Dann ist irgendwann auf dem letzten Produktree-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 ganze Tag noch 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.

Also wie man das halt bei Circular Imports machen würde, das ist ja ein generelles Python-Thema.

Und das ist sehr, sehr mühsam, was dazu sagt.

Lazy importieren und die Sachen da als Strings hinschreiben.

Genau.

Und wie das halt dann immer so ist mit Sachen, die mühsam sind, Leute machen sie nicht.

Umso einfacher Sachen sind, umso schneller werden und umso besser werden sie getan.

Und es gibt ein Pattern, das nennt sich Migration Zero und das hat sich jemand bei Medium 2018 ausgedacht, da sitzt da 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 habe 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, dass dieses Pattern implementiert und das ist im Endeffekt ein zweistufiges Ding.

Einmal habe ich einen Helper gebaut, der halt einem Verein quasi durch alle Apps 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 ja in der Datenbank in so einer 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 dem Django-Admin in Switch, den du sagen kannst, ja, jetzt habe ich Migration gelöscht, jetzt bitte beim nächsten Deployment, lass bitte, ne, 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 jetzt 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.

Meistens schon mal darüber gefallen, dass ihr irgendwie dann Migrations erinnert haben, dann bumm, oh, Datenmarkred nicht.

Genau.

Und ja, auf 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 Migration 2 genannt.

Ne, 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 aufs falsche 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 irgendwie immer benutzen.

Ich habe ja gestern nochmal über die Schultern geguckt, als du Django Cast migriert hast und irgendwie wie viele Migrations da allein von Weg her reingekommen sind.

Das waren ja hunderte.

Ich habe mir das auch überlegt, dass ich dich überall alle wegschmeißen möchte und normal.

Aber dann denke ich mir immer, das sollte ich vielleicht dann machen, wenn sich an der Datenbank nicht mehr so viel ändern hat.

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öderweise eine Library und ich werde Leuten.

Bei der Library geht es eh nicht, dann musst du dir, also da musst du ja mit Squashen arbeiten.

Ja.

Du weißt ja nicht, in welchem Stand quasi die letzte Person dein Package oder die Person dein Package nutzen.

Ja, vielleicht wenn ich bei irgendeiner Major, wie wir es

sagen, Release-Update und wer weiß, wie viele Leute außer Jochen seinen Jochen-Paket haben.

Ja, kann sein,

dass es nicht so viele sind.

Das ist schon richtig.

Schließlich nur in meinen Fuß und nicht in den Fuß von noch hundert anderen Leuten.

Das kann ich vertreten.

Das Risiko von Open Source Software, ja, genau.

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

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 Ractile 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 Reuse DB.

Ja.

Und dann musst du halt dafür ganz hart sorgen, dass alle Minus so wieder ausgeräumt werden.

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 es zum Beispiel, wenn man dann halt per Talks die ganzen unterschiedlichen Versionen durchgeht, dann muss man natürlich wenden, dass wenn man jetzt, da kann man nicht die gleiche Datenbank verwenden.

Da muss man halt schon die Datenbank wieder wegschmeißen, wieder neu machen.

Ja, es ist geht, aber es ist halt, es ist haklich, ja.

Ja, ja.

Ja, in seiner 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 ja, Community Talks und Tech-Talks mit vielleicht Metatalks, die irgendwie dazwischen sitzen, aufteilen.

Und in Edinburgh was relativ stark auf der Community-Seite.

Also Leute, die über Community-Erfahrung berichtet haben, die wo Parallelen gezogen werden zwischen anderen Arten von Communities, meine Erfahrung, wie ich das erste Mal zu Django contributed habe, solche Geschichten.

Das ist egal mit Edinburgh von mehreren Leuten die Kritik, dass das halt relativ viel war.

Und das ist mir jetzt positiv aufgefallen, dass ich fand, dass die Mischung aus den Community-Talks und aus den Tech-Talks und aus den Metatalks richtig gut war.

Und ich sehr, sehr happy war mit der Themaauswahl.

Ich meine, wie gesagt, das 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 finde das natürlich auch interessant, weil 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, sind viele Leute halt dann nicht so.

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

Ich glaube, eine Frau aus Katalonien, was ist so ein bisschen Definitionssache, was Spanien ist oder nicht.

Und ansonsten, ja, vielleicht ein, zwei, aber ich, wie gesagt, generell ist es, 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 Platin-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 alle veröffentlicht.

Das war sehr, ähm, sehr viel Information da drin.

Und ich habe mir nur ein ganz, ganz paar wenige Fotos gemacht und ich bin sehr gespannt, mir das Ganze noch in Ruhe zu Hause anzuhören.

Genau, wie die Background Workers, die Sache von Carlton Gibson, es gab coole Metatalks.

Also das fand ich von der, 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 harte Männerhand ist und das soll einfach vor allem die Mädels so ein bisschen ermutigen, dass sie das können.

Also nicht irgendwie das, ich glaube, da ist gar nicht so groß der Fakt, dass du da rausgehst.

Also das ist immer so ein Wort.

Positive Bestärkung viel und so, genau.

Genau.

Der U-Python ist auch, glaube ich, ein ganzer Workshop für Untergoogle zu.

Und ich habe, 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 einen Werkstudenten betreut oder sowas, echt interessant zu sehen, da diese, diese, dieses Coaching zu machen.

Und wie gesagt, das ist halt vor zehn Jahren, die war jetzt Jubiläum in Berlin gegründet worden, was ich auch ganz cool finde.

Also sprich, wenn jemand jemanden kennt, der, also ne, jemand eine Frau kennt, der 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, ja, Fuß ins Wasser halt mal wieder.

Und die Idee dabei ist, dass die halt im Endeffekt ihre erste Django-Seite erstellen und auch irgendwo hin deployen.

Und wie gesagt, der Fokus ist halt eher darauf, wie du schön gesagt hast, positive Bestärkung, denn ja, pädagogisch wertvoll.

Das Tutorial ist auch relativ gut und relativ komplett.

Wenn man auch mit Django ansteigen will.

Ich meine, das haben wir jetzt, vielleicht 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 wir weiter verraten.

Ja, aber das sind dann auch die Motivierten.

Bei denen lohnt sich das dann.

Ja, vielleicht tragen es in ihre eigenen Communities weiter.

Genau.

Du kannst ja einfach in der Linksammlung noch hinzufügen, da freuen die sich.

Ja, ja, mach ich auf jeden Fall.

Ja, ich habe das auch tatsächlich an die Neulinge bei uns mit Dango, auch einmal Dango Girls.

Also erst 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 einzugrufen, ich habe mich dann irgendwann kurz danach daran erinnert.

Es gab auch jetzt irgendein, muss ich auch nachgucken, welche 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 Datenbankqueries 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 Casp-Ding, was ich baue.

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

Also eigentlich, da dachte ich auch so, oh ja, das habe ich.

Eigentlich möchte man nicht.

Also wenn man in Templates Datenbankqueries macht, ganz blöde Idee, die sind dann so weit gegangen zu sagen, sie haben, sie benutzen so eine Art Class-Base-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.

Und das kann ich gut verstehen.

Das ist eine, also du willst eigentlich, wenn du zum Beispiel eine Daten, die Anzahl der Datenbankqueries unter Tolle behalten willst, willst du halt irgendeinen Punkt haben, wo du sagst, also hier, da sind alle Querys und ich mache nirgendwo anders welche, weil das ist so schwer zu containen, wenn man, wenn da irgendwas passieren kann, dass es halt ganz blöde Performance-Implikationen hat.

Und wo man dann quasi durch das Frontend auch Angriffe machen kann oder was?

Nee, Angriffe, als es einfach irgendwie das ist halt unheimlich, macht Dinge halt deutlich langsamer und man weiß gar nicht so, warum irgendwie.

Und ja.

Also zum Beispiel.

Warum wird das langsam?

Vielleicht müssen wir es nochmal genau erklären.

Die Datenbankqueries 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, wenn man irgendwie.

Naja, wenn man die halt alle an einer Stelle macht, dann ist es halt auch nicht so schlimm.

Also was auch, das ist, 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 Datenbankqueries sehr verstreut macht, dass das halt besonders schlecht ist auch.

Warum das genau ist, weiß ich nicht.

Was meinst du?

Weißt du, was, also an verschiedenen Stellen im Code, meint man 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, Dinge.

Auch erstaunlich viele.

Das weiß ich jetzt, weil ich es halt so ein bisschen geproffelt habe.

Bei mir sind es halt von, also weil wenn man jetzt einen Blog nimmt und da die List-Page und dann halt nur so fünf Artikel oder sonst irgendwas so, also aus diesem List-View, dann macht das halt so 110.000 Funktionsaufrufe oder sowas.

Was eine Menge ist.

Ich dachte so, wow, shit, warum ist denn das so viel?

Das ist ganz schön viel.

Und ich, mein Ding wäre jetzt, wenn jetzt so alle 1000 Funktionsaufrufe kommt, irgendwie die Datenbankquery, das ist schlecht.

Also so war es quasi vorher, irgendwie implizit, weil halt sind die Datenbankqueries halt da passiert, wo es halt aufgetreten ist.

Und das war, und einfach nur dadurch, dass ich jetzt das einfach mal so umgebaut habe, dass es jetzt diese Datenbankqueries, an denen ich selber noch gar nicht viel geändert habe, alle an einer Stelle passieren, ist es irgendwie doppelt zu schnell geworden.

Krass.

Und ich weiß nicht genau, woran das liegt, aber es ist auf jeden Fall, irgendwie scheint das so zu sein, dass auch der, nicht nur, dass man 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 Junge-Modelle gebaut werden oder ich weiß es nicht so genau.

Also das scheint alles nicht so richtig kostenlos zu sein, sondern das.

Also das heißt, wann irgendwas geladen wird an der Stelle und war es da irgendwie vorbereitet oder Tiert down oder so hin und her, kostet dann unheimlich viel, oder?

Ja, also 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, kann ich, 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, Timmy wusste ich und wenn das in den Ran passt.

Ja, das ist alles gar kein Problem.

Aber kann ich so eine Query formulieren?

Und wenn ich jetzt die Daten aus dieser Quer habe, kann ich die so transformieren, dass ich daraus wieder Django-Objekte machen kann.

Das ist halt so, aber 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, dass ich die halt auch, das ist auch sowas, wenn man cachen will, dann muss man das ja auch irgendwie in, zum Beispiel als Dikt haben, dass man halt auch irgendwie serialisieren kann.

Wenn du Django-Objekte hast, die kannst du nicht, also es gibt viele Dinge an Django, auf denen die kannst du nicht serialisieren.

Also du kannst es auch nicht cachen, weil Curry-Sets kannst du nicht gut cachen.

Geht nicht.

Aber wenn du jetzt das in eine Dikt-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 sagen, okay, die nächsten fünf Minuten einfach das Pfeil nehmen und nicht mehr die Datenbank fragen.

Oder irgendwo in den Hauptspeicher oder in Reddites oder sonst irgendwo hin.

Und dann kannst du das halt cachen.

Aber das, äh, genau.

Und aus den Dingern wieder Jungle-Modelle zu bauen, ist jetzt gar nicht so schlimm.

Da dachte ich auch so, das ist vielleicht schlimm.

Nö, ist gar nicht.

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

110.000 Funktionsaufrufe für ein Webseiten-Rendering ist nicht so richtig green.

Ehrlich gesagt, es ist eher so mehr so braun.

Aber weil du, ich hab gerade deinen Einstiegspunkt vergessen, der mich daran erinnert hatte.

Aber was war super interessant, bei diesem Dung of Girls Vortrag gab es auch so Success-Stories einfach, ne, von Mels, die das halt teilgenommen haben und die jetzt halt irgendwo einen coolen Job haben oder irgendwie eine coole Erfahrung haben oder irgendwo sich halt irgendwas Positives in ihrem Leben geändert hat.

So im Sinne von, ne, das hat einen Impact.

Und was ich da echt krass fand, war, dass eine US-Amerikanerin, die da teilgenommen hat, die halt vorher irgendwas gearbeitet hat und jetzt halt dann in Teingestiegen ist, weil sie halt am Ball geblieben ist, dass sie deshalb jetzt mit dem neuen Job eine Familie gegründet hat, also sprich ein Kind bekommen hat, weil vorher nach ihrer Aussage sie es in den USA sich nicht hätte leisten können.

Ich kann jetzt nicht bewerten, ob das stimmt, also ob das jetzt also eine absolut richtige Aussage ist.

Aber allein, dass es subjektiv so ist, hat mich echt schockiert.

Ja gut, aber ich meine, ich würde sagen, es ist halt, aber wenn man, also so ein Programmierer ist jetzt schon, ist jetzt auch nicht das Bestbezahlte überhaupt, aber sagen wir so, ist es halt schon deutlich besser wahrscheinlich als viele andere Sachen.

Vielleicht sollten wir gar nicht so viele Leute schulen, damit nicht so viel Wettbewerb da ist.

Das ist immer noch weiter gut bezahlt, wenn man sich auch hinter Probleme haben, unsere Kinder zu ernähren.

Ja, wie das man sagt.

Aber auch die, es ist ja nicht nur das Geld, sondern auch, dass man so eine gewisse Flexibilität hat.

Ich meine, ich meine, es gibt immer noch diese Marketingagenturen, wo man dann irgendwie bis nachts um zwölf irgendwie irgendwelche Marketing-One-Pager zusammenlötet, aber bei.

Nein, du hast völlig recht.

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

Ja.

Was übrigens, glaube ich,

Arbeit von zu Hause aus, als Mein Geld verdienen.

Hier ist ideal angewogen.

Nein, aber ich glaube, da sind tatsächlich so eine gesellschaftliche Transformation wäre ja sowas wie Vereinbarkeit einer der Hauptdinge auch, glaube ich.

Also fällt mir auch immer wieder auf, ja, das ist halt total hart, also wenn irgendjemand den ganzen Tag irgendwo hinfahren muss und mit Kinderbetreuung, das ist schon schwer, ne?

Ja, also ich meine auch jetzt die Erfahrung, in den letzten Jahren Erfahrung mit Kinderbetreuung, es passiert immer so viele Zeugs, wo man dann.

Also ich, ja, das wäre übel gewesen, wenn ich jetzt irgendwie hätte in einem Büro sitzen müssen.

Oder hinfahren jeden Tag.

Du wärst abend mal halb und abend ab.

Das ist gewesen.

Oder Schichtdienst einfach die ganze Nacht.

Ja, ganz übel.

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

Das ist mein Sword.

Das ist sehr beeindruckend.

Du wolltest jetzt über Party reden, auch wenn wir gerade für Kinderkriegen reden, dann

für manche Leute ein Thema.

Nach der Party kommt der Kater und

genau, 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 geht.

Dann gab es so eine Art Aufwandsentschädigung von nicht irgendwie 10 Pfund oder so.

Und was die nicht bedacht haben, ist, dass in vielen, also viele Leute gehen halt über ihre Agentur dahin, also auf irgendeine Art von Weiterbildungsbudget.

Und da buchen die Leute nicht selbst die Tickets und die werden halt am Blog von irgendjemandem aus zum Beispiel der Buchhaltung gebucht und die natürlich mit der Information, Party kostet extra, nichts anfangen können.

Und dann bei uns und auch bei anderen war es dann so, dass wir halt auf einmal alle nicht dahin gehen konnten.

Ach so.

Und weil einfach, weil halt das Häckchen 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.

Gehört eigentlich dazu.

Und ich persönlich finde nämlich die Party eigentlich immer eine sehr schöne Art, nochmal mit Leuten, die man halt vielleicht auch auf der Stage gesehen hat an den Tagen.

Die sind ja auch meistens den CD am Ende.

Aber das ist.

Die Real Pyson auch aufgefahren, da gibt es auch mehrere Partys, bei denen man sich extra registrieren muss, ja.

Und ich finde das eine sehr schöne Gelegenheit, nochmal in einem etwas lockeren, weniger ernsten Umfeld mit den Leuten.

Ich meine, viele Leute haben da irgendwie da noch mit den Leuten reden zu können, einfach auch nochmal mit Leuten connecten zu können.

Zum Beispiel in Porto, also jetzt vor zwei Jahren die Party war, glaube ich, eine der besten Partys.

Also die war super, das war echt gut organisiert, richtig schön Location, bestes Wetter, alles draußen.

Und da bin ich dann einfach in eine Runde von Leuten reingestolpert und dann bin ich halt nach mit einem im Gespräch hängen geblieben und nachher irgendwann meint er, weißt du echt, wer ich bin?

Ich so, keine Ahnung, ich bin Präsident hier von Jungle Software Foundation.

Oh, ups, sorry.

Ja, da kannte ich halt noch nicht so viele Leute in dem Umfeld.

Und das ist halt einfach, das würde halt so, ich meine, das kann passieren, wenn man so auf der Konferenz rumläuft, aber man ist da schon immer relativ getaktet mit, ne?

Dann ist irgendwie, dann gibt es da eine Verlosung und dann ist der nächste Vortrag und dann muss man sich vielleicht selber auf irgendwas vorbereiten, dann will irgendein, dann will irgendwie die eigene Crew irgendwas.

Oh, Konferenz-Experiments, da kann man auch eine eigene Folge zu machen, glaube ich, ja.

Und das fand ich tatsächlich, ich finde das einen sehr wichtigen Punkt, weil sie immer dann auch, ne, auch dann zusammen, naja, ne, sie sehen um so auf, nö.

Aber ich finde, das ist schon ein sehr, sehr schöner, sehr, sehr schöne Atmosphäre und eine Möglichkeit, mit Leuten nochmal so zu socializen, auch mal Leute ein bisschen persönlicher vielleicht auch kennenzulernen.

Und genau, also fand das wirklich schön.

Und jetzt bei diesem Mal, das war so ein bisschen doppelt unglücklich, dieses Konferenzgebäude in Vigo, das war direkt am Hafen.

Das war nicht so ein schöner Hafen, aber es war halt immerhin hat man mehr Blick.

Und die andere Seite der Bucht war schön.

Hat er eine gigantische Dachterrasse.

Also riesig.

Und genau oder fast genau die Party anfing, kam er das Gewitter, auf das wir drei Tage gewartet haben.

Ja, war dann blöd, weil dann mussten wir halt in die kleinen Gänge rein, die halt irgendwie so die Räume verbunden haben.

Und um neun war Schluss, was halt auch schade war, weil, wie gesagt, in Porto, glaube ich, waren bis eins oder zwei.

Ich glaube, in Kopenhagen davor war auch relativ lang, solange die Leute mehr oder weniger, oder wie lange, solange die Organisatoren halt Lust hatten, so dass das nicht abschließen zu wollen.

Und ja, das fand ich tatsächlich ein bisschen schade.

Er wird bestimmt seine Gründe gehabt haben.

Ich will mich da jetzt gar nicht auch irgendwie, ich habe nichts dazu beigetragen, ich will da nicht rummosern.

Ich persönlich fand es nur schade, weil, wie gesagt, ich das eigentlich meine, es ist einen sehr schönen Ort finde.

Und ich meine, auch da habe ich mich mit Leuten unterhalten, mit denen ich mehr oder weniger im gleichen Raum saß für drei Tage und halt vorher noch nicht gesehen habe, hatten interessante Gespräche.

Und genau, das finde ich immer einen schönen Ort und kann da auch nur eine Lanze dafür brechen.

Also ich würde auch sagen, Socializing bei diesen Konferenzen ist mit so der Hauptgrund, warum man da.

Ich finde das ja auch gestern war ja wieder bei DDF auch immer super, dass man danach noch was essen geht, weil da auch immer der Hauptteil des Spaß ist.

Das ist also nichts gegen die ganz tollen Vorträge, die alle tollen Menschen machen.

Mir halt auch bestimmt bei der DamboCon, wo gegen man auch dahin fährt und so, aber das Socializing ist ein großer Teil, dass man so Leute kennenlernt.

Also dass diese Experience, die man von anderen Menschen mitbekommt, die was ähnliches machen, vielleicht ein bisschen anders als man selber und sich darüber austauschen, ist schon super.

Also manchmal kann man auch selber mal ganz viel reden, das machen einige Leute gerne, aber auch manchmal zuhören ist auch super.

Und das ist irgendwie ja was Gutes.

Ich kann das auch sehr nachvollziehen.

Ich finde das auch mit den wichtigeren Teilen dann.

Also manchmal ist man das ja auf dem Gang so ein bisschen, ne?

Und weil du gerade sagtest, das fand ich interessant.

Deine Art und Weise war wahrscheinlich sehr strukturiert und sehr organisiert, möglichst viel von dem Content mitzubekommen.

Und also ich kenne ja, also von der EuroPisen kenne ich es zum Beispiel so, die ist ja lang und wenn man da halt die ganze Woche da ist, dann sind es ja sieben Tage.

Also zwei Tage Workshop, drei Tage Vorträge, zwei Tage irgendwas anderes.

Da tut es immer ganz gut, wenn man es die ein oder zwei Tage nicht ganz so vollpackt, weil man so ein bisschen sich so fließen lässt, weil dann kommt man mehr mit Leuten ins Gespräch, die auch irgendwo rumstehen, vielleicht, vielleicht näher nochmal an irgendeinen Stand und er hält sich da mit den Leuten länger, anstatt dass man jetzt sagt, okay, meine Uhr in zehn Minuten geht der nächste Vortrag los und der Kopf ist ja irgendwann eh voll.

Oder man bleibt halt dann nochmal länger auf der Party oder man geht halt dann am Wochenende mit Leuten, die man kennengelernt hat, nochmal in die Stadt oder spazieren oder was von der Natur anschauen oder sowas, was auch irgendwie, glaube ich, mit dazugehören kann.

Aber das ist halt witzig, weil es so unterschiedliche Herangehensweisen gibt und ich halt auch Leute gesehen habe, die jetzt ganz anders machen.

Es gibt Leute, die kommen halt nur für zwei Tage und da ist das halt dann sehr intensiv.

Oder es gibt Leute, die sind nur in den Workshop standard und dann nie wieder gesehen.

Oder Leute schaffen sogar nur zu ein oder zwei Vorträgen, was manchmal an Kinderbetreuung liegt oder sowas, die man da auch netterweise hinbringen kann.

Oder halt nur sogar Notrin-Sprints gab es, glaube ich, auch Menschen, die halt wirklich nur da hingegangen sind, um mit den Leuten an Sachen zu arbeiten.

Aber das ist so witzig, weil diese, das ist so ein bisschen, ich weiß nicht, ob es eine Kulturfrage ist, aber so diese Art und Weise ändert sich je nach Lebensphase oder wo du gerade selber bist, total.

Und das ist, glaube ich, auch eine der Herausforderungen für so Konferenzen, für die unterschiedlichen Ziele, die die Leute so mitbringen, irgendwie gut ausgestattet zu sein.

Absolut.

Und mich würde dieses Django-Conding auf jeden Fall auch mal reizen, ehrlicherweise.

Ich finde das auch mal ganz nett.

Ist halt ein bisschen mehr Fokus auf Django, was auch mal cool ist.

Also nächstes Mal ist es in Dublin, das ist auch nicht verkehrt.

Ah, okay, da war ich jetzt schon, ja.

Aber ja.

Ich auch, ich fahre trotzdem gerne nochmal hin.

Ich bin Dublin super.

Toll, ja.

Weißt du auch schon wo?

Gibt es schon ein Ort?

Okay.

Nein, also es gibt, glaube ich, die eine Webseite, wo literally das Logo drauf ist.

Alles weitere folgt dann.

Find's auf jeden Fall sehr cool.

Ja, der Edinburgh und Vigo hätte ich wahrscheinlich beide auch gemacht.

Und Vigo kann ich noch nicht, Edinburgh schon.

Und ja, der Dublin, ja, ist das einfach eine tolle Stadt.

Wenn ich noch Bier trinken dürfte, wäre irgendwie ganz toll.

Überall wunderschöne Sachen.

Du musst halt Whisky trinken.

Ja.

Am Shannon entlang ist ja immer toll.

Da gibt es tolle Sachen.

Ich meine, das ist halt sehr moderne, Hilfe Stadt auch, ne?

Naja.

Gut, das sind die meistens alle irgendwo bis auf vier Wochen.

Tja.

Aber das waren jetzt aber drei Tage quasi.

Genau, das waren drei Tage Konferenz.

Da waren immer wieder, also die hatten eigentlich nur eine, also es gab einen Konferenztrack und dazwischen gab es immer wieder mal in einem anderen Raum dann die Workshops.

Ich habe die Workshops nicht teilgenommen, ich nehme irgendwie von diesen Workshops nicht so viel mit.

Ich habe auch, ich war letztes Mal in Ellenburg mal bei den Sprints dabei und man muss auch sagen, das ist kein Umfeld, wo ich wirklich produktiv arbeiten kann.

Also dann sitzen da ganz viele Leute in einem Raum und es ist halt so ein gewisser Geräuschpegel.

Weiß ich nicht, jedem zweiten fehlt irgendwie Strom und dann hast du da kein Ladekabel und es ist, also es ist unruhig.

Interessant, also ich finde das mit dem Workshop total anders.

Alle weil, vielleicht bist du schon viel weiter als ich mit vielen Punkten, aber unwahrscheinlich.

Die Dinge, die ich da so mitgenommen habe, habe ich immer super viel gelernt.

Und das hängt wahrscheinlich total davon ab, was für einen Workshop man da hat und welches Niveau da ist.

Und wenn man eine gute Auswahl hat, findet man bestimmt was.

Also ich habe wirklich immer da am meisten von bekommen, mehr als von den vielen Talks.

Aber ich glaube auch, was, ich gehe halt auch ganz gerne auf die Konferenzen, nehm dir die Stichpunkte mit und sortiere dann quasi danach nochmal so ein bisschen aus, so was speichere ich ab, als es existiert irgendwo.

Zum Beispiel diese Sache mit der Architektur, das finde ich super spannend.

Ich müsste auch nochmal, also ich gehe da auch nochmal ins Gespräch mit ihr und guck mal, ob wir sie vielleicht mal zum Django Meetup Köln oder sowas einladen können oder sowas.

Weil das ist halt ein Thema, das halt für mich super spannend ist und wo ich auch noch definitiv zu wenig weiß.

Und das ist das ist, wo gehe ich dann damit um?

Also das

heißt jetzt nicht, vielleicht dass ich dann eine Länge der Workshop habe.

Also die Workshop ich hatte, waren halt mindestens einmal einen halben Tag, also vier Stunden oder so.

Und das, also ich bin da richtig tief in die Themen reingekommen, hab mich da richtig reingehackt, hab auch wirklich was gemacht und hab dann auch teilweise noch wirklich nachgearbeitet und die Dinge wirklich umgesetzt und benutzt.

Also da sind

die eher kürzer, also ich glaube so ein bis zwei Stunden, glaube ich.

Ja, nicht ganz sicher.

Ich habe letztes vor letzten Mal habe ich mal welche mitgemacht, aber wie gesagt, irgendwie die Atmosphäre ist nicht so ganz.

Also ich konnte zum Beispiel auch konzentriert arbeiten, weil es da ruhig war.

Und wo ich direkt gehen muss, bei den Sprints, Sprints sind immer sehr chaotisch.

Meistens, also ich nutze Sprints oft dann auch zum Socializen, mit den Leuten quatschen, um nochmal rumrum zu stehen.

Ja, genau.

Aber ich muss ehrlich geschehen, ich habe bei den Sprints auch immer nicht das Thema gefunden, wo ich sagte so, wow, das finde ich jetzt super toll, da will ich jetzt mitmachen.

Weil ich glaube, dass das, wenn du idealerweise vielleicht, wenn man ein Thema bei dem Sprint hat, wo man vielleicht sogar schon drin ist, wo man das ganze Setup schon gemacht hat, wo man die Entwicklungsumgebung bei sich auf dem Rechner schon eh drauf hat und dann sich einfach einloggen kann, dann kann man sich ein Feature zunehmen, das mit anderen Leuten mal so diskutieren, durchdenken und dann von mehreren Seiten mal echt mal die Lösung, die man gerade hat, mit drei oder vier Leuten, die da fokussiert dran arbeiten, wirklich implementieren.

Das ist auch cool,

glaube ich.

Auf jeden Fall, auf jeden Fall.

Also wir haben ja auch beim Django Meetup in Köln jetzt im Januar, hatten wir Sarah A.

und Thibaut, also die sind beide Django Board-Members, ganz frisch geworden, hatten wir eingeladen, sind netterweise vorbeigekommen.

Da haben wir auch einen Open Source-Sprint gemacht.

Der schon am Mittags war, wo ich leider erst zu spät konnte, ja.

Und das war auch echt cool.

Also es war eine coole Erfahrung.

Jeder hat da so ein bisschen an dem gearbeitet, wo er, wo er drauf Lust hatte.

Es sind mehrere Tickets auch erstellt worden.

Und also wurde da mehrere Pull-Requests auch erstellt worden.

Und danach hat man noch so ein bisschen Diskussion, so Future of Django, was auch super interessant, weil man halt wirklich mal zwei Boardmanners am Start hat und die dann wirklich mit denen so ins Eins zu eins gehen kann.

Aber wie gesagt, ich bin da gar nicht dagegen oder so.

Ich sage nur, das ist halt nicht so mein Arbeitsumfeld.

Ich finde es fürs wirklich programmiert.

Also kategorisch, ja, also es ist nicht nur so zufällig gewesen, sondern denkst du wirklich, brauchst du eher deine Ruhe.

Ja, definitiv.

Aber das, was ich dann interessant finde, ist, dass du zwischendurch, also ich weiß nicht, ob sich das geändert hat, sagtest, dass du im Büro total dich für eine Arbeitsatmosphäre hast und dass sogar zu Hause vorziehst.

Wo ich immer sagen würde, im Büro habe ich immer den Stress, das mache ich lieber zu Hause.

Also jetzt, wo ich wieder öfters ins Büro gehe, also ich mache so drei Tage, Büro, zwei Tage zu Hause, ist am, also nur einen Tag die Woche im Büro war, dann hast du halt ständig irgendjemanden, mit dem du dich über die letzte Woche austauschen musst.

Das lenkt dann schon sehr ab, aber du drei Tage da bist, dann hast du halt deine Nasen alle gesehen und dann streckt sich das so ein bisschen über die drei Tage und dann ist es eher, dass wenn man eh mal gerade eine Pause braucht und mal kurz zu die Tür geht oder so, dass man halt damit jemanden hat, mit dem man reden kann.

Das finde ich ganz angenehm.

Und tatsächlich ist auch, dass post Corona bei uns auch einfach nicht so viele Leute in Brosen, dass wirklich da ein gewisser Lärmpegelob entstehen könnte.

Ich meine, natürlich telefoniert vielleicht mal irgendwer, irgendwo oder so, aber es gibt ja immer noch Kopfhörer.

Dann bin ich ein Boden, dann muss ich eine Hose anziehen, das ist ja fürchterlich.

For the record, du hast jetzt auch eine Hose anziehen.

Jetzt hast du mir gespoilert.

Nein.

Ich wollte jetzt keine niemanden nahe drehen.

Ja.

Ja, wir könnten noch Picks machen.

Das klingt, glaube ich, ganz gut.

Und dann ist eigentlich auch schon eine runde Sache.

Ja, dann bin ich ja mal gespannt, was für Pics wollt ihr denn nehmen?

Vielleicht doch ein Willst du halt.

Du hast den Familie geklaut.

Ich weiß gar nicht, habe ich den schon gesagt.

Das kann sein.

Ich habe mich in letzter Zeit nochmal so ein bisschen, also es gibt da auch einen sehr schönen, das kann ich vielleicht dazu sagen, Vortrag von Simon Willison zu einem Kommandozeilen-Tool, was er geschrieben hat, namens LLM.

Ja, das ist ein bisschen.

Und das LLM picke ich mal, weil da habe ich jetzt auch wieder ein bisschen mehr mitgemacht.

Und das ist halt wirklich nett, weil man da unterschiedliche Modelle mal so ausprobieren kann, damit man so ein bisschen rüber spielen kann.

Aber auch,

du kannst halt einfach in deine Kommando-Zeit reinpipen.

Genau, du kannst halt, also ich benutze es dann halt auch für solche Dinge wie alle.

Ich habe jetzt sogar eine Funktion tatsächlich für Django Cars geschrieben, wo ich sagen kann, gib mir doch mal den gesamten Source-Code aus oder gib mir mal den gesamten Source-Code mit Tests aus.

Oder so.

Und dann und mach mir das zu einem Prompt, wo dann halt die Dateinamen auch noch immer mit drüberstehen.

Und dann kann ich sagen, okay, pipe das mal irgendwie in ein Modell rein und dann mache ich da irgendwie einen System-Prompt zu, von wegen, ja, habe ich bei der Dokumentation irgendwas vergessen oder kann man das irgendwie, gibt es so offensichtliche Dinge, die man irgendwie besser machen kann und so.

Und ja, das funktioniert tatsächlich ziemlich gut.

Alle Anfragen und Antworten landen in der SQLite.

Das heißt, hinterher kann man sich auch gut angucken, was da, also man hat alle Sachen, die man je irgendwie gepromptet hat und wo man Antworten gekriegt hat, hat man in einem strukturierten Format, das man halt auch wieder irgendwie auslesen kann und analysieren kann.

Total hast halt deine Templates verwenden, die man halt auch dann hintereinander pipen kann und dann kann man auch das Default-Template überschreiben, wenn man will und so.

Da hat man halt immer schon sein Systemprompt und sein Alignment so ein bisschen vor oder hinter dem ganzen Zeugs, was man da kommuniziert.

Das finde ich auch super cool.

Man kann jetzt, also ich habe zum Beispiel so einen, den nenne ich dann den Senior, brauche ich dann das Template Senior, dann gibt er eben immer schnippische Antworten, wie sich das von Jochen immer kenne.

Nein, ähm.

Es funktioniert super, es macht Spaß und der sagt immer so, ha, warum hast du das denn nicht selber rausgefunden?

Du hättest auch die Anleitung lesen gehört.

Das ist toll und es macht so ein bisschen Spaß beim Arbeiten, wenn man dann Fragen stellt und jemand der dann so antwortet.

Sehr lustig, ja.

Sehr gut.

Genau.

Ja, also das Ding, ups.

Ja, das wäre dann mein Pick, genau.

Ja, äh, Ronny.

Boah, so ganz spontan fallen mir nicht mehr Sachen ein.

Du kennst etwa die Praxis nicht von dem Pick der Woche, des Monats hier bei uns im Podcast.

Also ich kenne das doch, aber mir fällt gerade irgendwie nichts wirklich ein, was ich nicht gerade schon irgendwie in irgendeiner Art und

Weise erwähnt habe.

Interess gesehen.

Oder du kannst ja, genau, wenn du einen Talk zum Beispiel bei der Django-Con super gefallen hast, dann können die Leute ihn jetzt noch nicht sehen, aber irgendwie sich schon mal darauf freuen, dass es den dann später irgendwo auf YouTube

gibt oder so.

Also wie gesagt, der Talk über die Layered Architecture bei Django, ich weiß nicht genau, wie er hieß, der war auf jeden Fall sehr spannend.

Und auch einen Talk, wenn man sich für Django Django interessiert und auch in die Idee bezüglich großer Applikationen und wie lässt man eine Django-Applikation wachsen, weil ich bin schon davon überzeugt, dass man auch große Applikationen damit bauen kann.

Es ist nicht nur zwingend, nur dieses kleine Blockding, womit es mal angefangen hat.

Da gibt es einen Talk, Scaling Django to 500 Apps.

Das ist auch Kraken, hier Octopus Energy Related, glaube ich.

Und die haben eine Idee von, also Django-Apps ist halt im Endeffekt eine Art und Weise, wie man den Code kapselt.

Das haben ja viele Frameworks.

Und die haben da eine Idee, die, ähm, ja, Ingenieur, sie missbrauchen da ein bisschen das Framework, machen was, was nicht vorgesehen war, was aber trotzdem funktioniert, nämlich die machen Sub-Apps.

Und haben da so eine Spitze-Naming-Konvention, um im Endeffekt zu sagen, ich hab, ich möchte, ich habe immer noch eine Domäne, die sich um mein Projekt oder mein Accounting oder mein Weiß der Geier was kümmert, mein Produkt, aber da drin, das ist so groß geworden, ich möchte das weiter strukturieren.

Und das finde ich super spannend.

Das ist gerade auch eine Sache, über die ich sehr aktiv nachdenke, wie ich das in mein Projekt, in dem ich aktuell arbeite, reinbringen kann.

Weil ich jetzt zum Beispiel in meinem Projekt, wir haben es, wir haben da so ein bisschen, also manche Apps sind einfach riesig geworden, wo man sagen muss, die müssen aufgeteilt werden.

Und mit diesem Sub-App-Gedanken bin ich heute einfach nur in der, in diesem Structure View, also wo man quasi sieht, welche Klassen gibt es in meiner Datei.

Einfach mal mit einem Blick sind mir und meinem Kollegen wirklich einfach so, okay, das ist ein Kontext, also das ist so eine Sub-App, das ist eine, das ist eine, also es war super schnell wie so Sachen reingefunden, wo man auch sagt, okay, das gehört hier echt gar nicht rein, das muss eigentlich komplett woanders hin.

Einfach nur mit einem Blick und diesem Gedanken, dass es dieses Sub-App-Pattern gibt, dann auch bei ein paar Sachen gesagt, okay, das ist definitiv keine Sub-App, das muss einfach, das ist Standalone so, das kann man gut rausziehen.

Das finde ich auf jeden Fall einen sehr interessanten Vortrag, den ich jedem ans Herz legen kann, der sich für sowas interessiert.

Sub-Apps habe ich auch immer letzte Woche in irgendeinem Projekt eingebaut, aber ohne das Pattern jetzt so zu.

Aber ich bin eigentlich eher, gut, vielleicht bin ich da irgendwie falsch abgebogen, aber ich bin eigentlich eher so auf dem, ich mache gar keine Django-Apps mehr.

Weil, also immer wenn ich, wenn ich so, naja, einfach ganz stinknormal mit Python-Bortmitteln Dinge modularisieren.

Modulare, ja.

Weil das Problem bei den Apps ist halt einmal, ja, es ist halt irgendwie so eine Spezialgeschichte, die halt irgendwie anders funktioniert als alles andere und musst es halt auch in den Settings ja immer dann mitsetzen und so.

Und dann, das, was ich eigentlich am fiesesten finde, ist, dass man halt, wenn man kann halt Sachen schlecht refactoren, so von einer App zum Beispiel in eine andere, man kann die Migration nicht umziehen.

Aber so Modelle, genau, wäre so ein Punkt, wo ich sagen würde, eine App, wenn es irgendwo Modelle gibt, ist für mich immer bisher so eine App.

Ja, aber was machst du dann, wenn du mal das eine Modell in eine andere App ziehen willst?

Das ist mühsam, das habe ich schon gemacht.

Es geht, aber es ist mühsam.

Also weil, ja.

Also musst du halt mit Raw SQL und Daten halt schon.

Ja, ja, klar, du kannst natürlich, das geht schon, aber es ist halt nicht einfach, man verschiebt es und da kann man auch was kaputt machen.

Ja, genau.

Wenn man es halt alles in einer App hat, sozusagen, dann kann man es einfach umziehen und es kann.

Das ist eine interessante Idee, habe ich nicht drüber nachgedacht.

Dass wir diese Model Micro-Diskussion haben.

Ich hab meistens dann das Modell Models, also wenn es größer wird, dann habe ich halt ein Models-Verzeichnis.

Aber wir haben Models

in einer Datei.

Nee, genau, das eben nicht mehr, weil das wird dann halt riesig.

Also, wenn Models irgendwie größer wird als tausend Zeilen oder so, dann würde ich denken, na gut, wahrscheinlich sollten wir es mal ein bisschen aufteilen.

Und ja, dann kann man die ja auch so gruppieren und dann hat man noch eine Init-PY, in der man dann halt irgendwie festlegt, welche überhaupt exportiert werden sollen, weil viele Dinge braucht man gar nicht nach außen reichen, sondern rein intern.

Das ist interessant, da habe ich nicht drüber nachgedacht, um so ein API zu sehen.

Ja, das finde ich auch.

Also ich mache halt so unter Verzeichnis, dass nur bestimmte Sachen rauskommen und die anderen Sachen, also dann implizit intern.

Das ist interessant.

Da habe ich heute noch darüber nachgedacht, aber auf diese, auf diesen, das ist ein Benefit, das habe ich nicht drauf gekommen.

Interessant.

Ja.

Ja, cool.

Und dein Pick?

Mein Pick, ich habe natürlich wieder von Jens geklaut, der das in unsere Gruppe geschrieben hat, das ist Monkey-Type.

Das wird auch von Instagram entwickelt worden, wenn ich das richtig verstanden habe.

Und das baut dir Type-Annotations.

Das heißt, du gehst einfach hin und hast irgendeine Python-Funktion oder sowas und sagst dann Kommandozeile Monkey-Type und dann nimmt der halt die Pfeile oder das Ding und schreibt da da die Annotations dran.

Und das ist gar nicht so schlecht.

Also es funktioniert besser, als man vielleicht denkt.

Ja.

Und ja, wenn man halt gerade nicht so weiß, dann möchte ich irgendwas Hype-Ontieren, also warum man auch immer das mal möchte, dann macht man das doch.

Und dann sieht man, was da passiert.

Das kann einem schon ein bisschen Arbeit abnehmen.

Und irgendwie nicht.

Man entdeckt manchmal sogar auch Bugs, dann hast du, hä, nee, das stimmt aber eigentlich gar nicht oder so.

Dann hat man andere Sachen erwartet.

Oder oh, Mist, dann bekommt auf einmal der Delinter oder MyPay sagt halt so, nee moin, der Das stimmt aber jetzt gar nicht.

Das ist schon ganz gut.

Interessant.

Ja.

Ja, dann würde ich sagen, haben wir

für heute die Episode.

Dann herzlichen Dank, dass du wieder da warst von dir.

Ja, ja, ja.

Vielen Dank.

Dann machen wir es gleich noch unter uns weiter, würde ich sagen.

Herzlichen Dank fürs Zuhören.

Bleibt mit dem Bogen, wo ihr mir auch seid.

Danke, Jochen.

Und ja, Feedback an hallo.pythonpodcast.de, Feedback an Regon, Kommentare, Lob, Kritik und so weiter.

Was ihr alles möchtet.

Bis bald.

Bis dann.

Diesmal ganz lange warten.

Tschüss.