Hallo, liebe Hörerinnen und Hörer. Willkommen beim Python-Podcast, Episode 57.
Heute reden wir über die DjangoCon. Hallo, Jochen.
Hallo, Dominik. Und hallo.
Und hallo, Ronny.
Ronny.
Hi. Schön, dass du wieder da bist.
Ja, wunderbar.
Freue mich auch.
Dann fangen wir vielleicht mit ein bisschen News an und dann schlagen wir direkt ein, was denn da so kommt.
Jo, ich mache hier meine Kapitelmarke für News.
Okay, Kapitelmarke hat nicht funktioniert. Ah, toll. Nichts funktioniert hier?
Das ist ja nichts Neues.
Ja.
Das sind keine News.
Wann war die nicht angekommen?
Vielleicht erst mal damit an.
Ah ja, ja.
Die war Anfang Juni in Vigo in Spanien,
Nordspanien, Galicien.
Eine sehr schöne Stadt.
Ohne jetzt tatsächlich große Highlights,
aber mir hat es trotzdem gut gefallen.
Es ist ein sehr schöner Nationalpark,
ein Inselnationalpark direkt vor der Küste.
Wäre mal die Gelegenheit, da hinzufahren.
Das sollte man nicht verpassen.
Zeit, wandern zu gehen.
Ist das so quasi da irgendwo diese Santiago de Compostela?
Ja, genau.
Das ist so ein bisschen südwestlich davon.
Also genau nördlich von Portugal.
Und genau, ich hatte einen Tag
Zeit, wandern zu gehen, auf der
Isla Cies, glaube ich.
Und das ist
wirklich sehr zu empfehlen.
Klingt sehr gut.
Ja.
Nächste Woche ist Europython, vielleicht das News.
Ich weiß nicht, ob man das noch hört. Wenn ihr darüber hört,
vielleicht ist es ja schon vorbei. Ja, wahrscheinlich.
Ja.
Wir möchten
gerne ein paar Themen von der DangoCon hören.
Und es gibt aber noch ein, zwei andere News.
Ja, genau. Also wir haben ja jetzt schon einige
Zeit keine Sendung mehr.
Das ist immer dasselbe Problem im Moment,
aber gut.
Also ein News ist ganz interessant.
Google ist ja so ein bisschen unter Druck in letzter
Zeit. Man sieht sie halt öffentlich schwitzen.
Dieses
ganze AI-Thema, das ist irgendwie
ja,
können sie nicht so richtig entscheiden. Steigen sie jetzt voll ein
oder doch nicht? Was machen sie? Oh nein.
Ja, und jetzt haben sie sich für etwas anderes
entschieden, nämlich ihr Patentime-Team zu feuern.
Die haben dabei, glaube ich, direkt wieder ein neues eingestellt.
Ich glaube, in Deutschland sogar.
Ja, sie sind jetzt, was, alles zu teuer mit dem teuren ...
Die Amerikaner wollten alle 300.000 Dollar haben pro Jahr.
Haben sich irgendwann gedacht, das können wir in Deutschland auch für die Hälfte haben.
Genau, dann gehen wir halt in so ein Billiglohnland
und dann in so eine, keine Ahnung, Billigvorstadt.
Und zwar gehen sie nach München und wollen da ein neues Team aufbauen.
Da sind sie ja auch schon, da sind sie ja auch schon ein bisschen gewachsen.
Aber ich bin mal gespannt, ob das klappt.
ob sie da jetzt irgendwie, keine Ahnung,
äquivalent rekrutieren können.
Mal sehen.
Aber ja.
Ja, dann bestimmt erkannt, wo die guten Peißenleute sitzen.
Und wenn man in München guckt, die sind ja eh immer ganz oben,
wenn man sie fragt.
Entschuldigung, ich wollte jetzt keinen Lokalpatriotismus hier auffangen.
Ja.
Genau, also das ist schon mal irgendwie,
aber normalerweise ist das ja nie passiert.
Das ist ja immer so, mehr Peitenleute einstellen und so, voll gut.
Und jetzt, und welche, hat man das irgendwie so rückgebaut?
neu. Vielleicht ist aber jetzt
einfach nur so eine normale Glättung, die irgendwann mal ist, oder?
Ja, kann auch sein, ja. Also vielleicht ist auch,
muss man da nicht so viel rein interpretieren, das ist schon richtig.
Es gibt tatsächlich von Python 3.13
jetzt so erste Beta-Versionen.
Das heißt, wenn man mal ausprobieren
will, ob das eigene Zeugs, was man so baut,
irgendwie damit tut, dann kann man das jetzt mal
machen und...
Tut eigentlich, ne? Ja, es gibt glaube ich
jetzt auch, wo war das? Irgendwas kann jetzt auch,
man kann jetzt auch Wheels bauen für
3.13.
Ich habe heute echt keine Zeit gehabt,
mich die News nochmal anzugucken.
Insofern tut mir leid, wird etwas durcheinander.
Aber ja.
Da müssen wir auch mal durch.
Python 3.13 kann man auf jeden Fall jetzt mal so.
Jetzt ist der richtige Zeitpunkt, um das mal auszuprobieren.
Was habe ich noch?
Oh, ich habe gesehen, es gibt,
ich weiß aber nicht, ob das News ist,
aber es gibt ein Software-Development-Kit für One Password.
Also ich bin immer noch bei One Password.
Mir tut das zwar etwas weh, dass das alles super teuer ist und so,
aber ich finde es immer noch so, der beste
Passwortmanager und der hat
jetzt auch einen Python-API
im Software
Development Kit gekriegt. Das heißt, man kann von
Python aus irgendwie One Password anfragen.
Also sozusagen, man kann halt Python
Sachen schreiben und dann fragt das Ding halt
One Password und dann sagt das Ding halt da,
guck hier mal in die Kamera oder hier,
leg mal da deinen Finger drauf und dann kann man sich authentifizieren.
Was ja für manche Sachen ganz nett ist.
Wie teuer ist denn das? Weißt du das?
Wenn wir Werbung machen. Eigentlich hätten wir die
Das kostet, die haben ja auch wahnsinnig viel Fremdkapital aufgenommen und das kostet pro User irgendwie sowas 35 Dollar oder Euro im Jahr ungefähr.
Und das ist halt schon, ja.
Und gab es Debatten, wie lange ist der letzte Breach her?
Ja, es gab einen auch über Okta, der war aber nicht so furchtbar schlimm, also ist auch so ein halbes Jahr her, glaube ich, oder so.
Ja, ich wollte gerade sagen.
Ja, genau. Was haben wir noch? Achso, ja, es gibt auch gute Nachrichten. Das ist ja auch so ein Ding, da kriege ich immer Angst, wenn ich mir angucke, wie das so funktioniert. PyPI macht wahnsinnig viel Traffic. Also was darüber geht, ist halt atemberaubend und es kostet auch wahnsinnig viel Geld.
Und das funktioniert halt darüber, dass es einen CDN, so Content Delivery Network Anbieter gibt, der sponsert das halt, der hostet PyPI. Und ich weiß nicht, was man zahlen müsste, wenn man das nicht irgendwie kostenlos kriegen würde. Es wäre sehr viel und das wäre ein Riesenproblem, weil ja, per Pip installieren würde dann halt nicht mehr funktionieren.
Und die haben jetzt gerade auf der Python US verkündet,
dass sie für fünf weitere Jahre PyPI sponsern wollen.
Cool, cool.
Das ist natürlich praktisch.
Also es gibt Py ist noch mindestens fünf Jahre.
Ja, genau.
Dann tatsächlich jetzt im Juni vor zwei, drei Wochen
ist NumPy 2.0 erschienen.
Nach irgendwie, ich weiß nicht, 14 Jahren Entwicklungszeit.
Das war eine ganze Zeit lang in Progress.
Und
genau, ist vielleicht
jetzt nicht der günstigste Moment, um zu steigen,
sondern man sollte vielleicht das erst mal auf
kleiner zwei pinnen oder so und dann mal gucken,
bis alle anderen irgendwie sich
angepasst haben, weil das bricht halt
einige
Geschichten. Aber ja,
schön, dass es jetzt raus ist und dann
es macht einige...
Wie gesagt, ich habe keine
Ahnung, was alles genau passiert ist oder ich wusste es mal,
hab es wieder vergessen.
ja, Performance ist irgendwie besser geworden.
Es sind auch ein paar Updates, das heißt,
ihr müsst ein bisschen aufpassen, weil wenn ihr da irgendwie einfach
updatet, dann kann es sein, dass euch
relativ viele Dinge kaputt gehen.
Also ich habe so ein paar Updates gehabt, da war es
so ein bisschen hässlich, weil
ich tatsächlich downgraden musste,
weil da irgendwie Pakete irgendwo
ganz tief drin waren, die dann
leider nicht mehr wollten und die man halt
umbauen hätte müssen oder sowas, wo man dann erstmal
verstehen muss, was alles ist. Das dauert alles relativ viel Zeit.
Nicht so schön, aber
waren ein paar Upper Boundaries dann
in den Projekten auf einmal drin.
Ja. Aber gut,
das ist eigentlich super, dass man
halt, das ist auch eh ein Semantic-Version-Ding,
2.0, Breaking-Api-Changes,
what happens. Genau.
Genau, dann gibt's
eine neue, also eine erste
1.0-Release von Polars,
was ja auch vielleicht ganz
nett ist, dass man sich
jetzt halt so drauf verlassen kann, dass die Api da mal
eine Zeit lang stabil bleibt und so.
Und da ist auch sonst nichts Großartiges
dazugekommen. Nutzt du das
irgendwo viel oder ein bisschen?
Nee, viel nutze ich das nicht. Ich nutze das ab und zu mal, aber
Pandas oder ist das egal? Ich nutze eher Pandas,
weil ich mich halt da so an Pandas gewöhnt habe.
Ja, aber nur, weil du dich dran gewöhnt hast.
Ja. Pandas haben die auch ein bisschen schneller gemacht. Ich weiß gar nicht,
gibt es irgendwie wirklich jemand, der das mal getestet hat,
was so für was besser geht?
Ja, also Polars ist tatsächlich,
wenn man einfache Sachen macht, ist es halt
ein gutes Stückchen schneller.
Es gibt halt Dinge, die gehen mit
Polars gar nicht so und die gehen mit Pandas und dann
und ich meine, ich habe mich an diese, also viele Sachen
sind halt auch total komisch. Und ich habe mich halt dran gewöhnt.
Zum Beispiel an diese Multi-Index-Geschichten
und so. Und
wahrscheinlich ist es keine gute Idee. Und es ist richtig,
dass Bollers das alles nicht gemacht hat. Und auch selbst
die Leute, die Pandas gebaut haben.
McKinney sagt heute im Podcast so,
ja, das mit diesen ganzen komplizierten Index-Geschichten
und so, das war wahrscheinlich alles nicht so richtig.
Aber wenn man sich mal dran gewöhnt hat,
dann
ist das halt klar, wie man das damit macht.
Und alles andere muss man halt dann denken.
Ja, deswegen benutze ich halt eigentlich
immer noch lieber Pandas. Aber
ja, ich glaube
Polas ist schon der richtige Weg eigentlich.
Ja, genau.
Was gibt es noch? Psycho-PG
3.2 ist raus, also
auch etwas, ich weiß
nicht, ob alle schon umgestiegen sind auf 3,
also ich habe das wahrscheinlich...
Es gab ja Psycho-PG 2 explizit
und wenn man jetzt aber normal Psycho-PG nimmt,
dann ist das jetzt normal 3. Ja, genau.
Und
ja, super, da ist halt auch
so Essing-Support
jetzt mit drin und diverse
Geschichten. Also
Auf Postgres 15, was ist das Minimum
für Seiko BD?
Warte mal, lass mal grad gucken.
Bestimmt auch bei Tifa.
Wahrscheinlich, ich würde jetzt tippen, Postgres 12 oder so.
Minimum steht da nicht.
Nee, steht, steht,
ich weiß es. Keine Low-Hanging Fruit.
Auch nicht so wichtig. Die meisten
Leute, sind die bei alten Datenbanken oder bei neuen? Was meint ihr?
Ich denke alte Datenbanken,
weil die meisten halt nicht die Kontrolle haben
über die Distributionen, auf denen ihr Zeugs läuft.
Und dann haben sie halt irgendwie entweder alte Datenbanken,
weil Datenbanken auch oft nicht kontinuierisiert sind.
Oder sie haben es kontinuiert und haben dann vergessen,
dass es irgendwie ...
Aber in der Praxis sehe ich ganz oft alte Datenbanken.
Ja, stimmt.
Und ehrlich gesagt, ich finde es komisch,
weil das ist halt so ...
Ich meine, es kostet eigentlich ja nicht viel,
das abzudaten oder da abzudaten zu bleiben
und es bringt halt ordentlich was, also
eben, wenn ich jetzt mir angucke, so
Postgres 12 oder so, was ich häufig sehe, oder
äh, selbst, also
bis, wenn man jetzt stattdessen ein
Postgres 16 nimmt, dann ist es halt schon, da hat sich
schon einiges getan, also
kriegt man irgendwie so 30% Performance
Proofment einfach so gerade.
Ja, also, ja.
Genau, ähm,
ja, äh, dann, oh,
HTMLX 2.0 ist erschienen,
auch ganz interessant, da hat sich auch nichts
geändert, sondern das ist einfach nur
hochgezählt und
gut, ist ein paar Sachen entfernt worden.
Also ein paar Extensions,
die Websockers-Extension ist nicht mehr drin
oder ein paar Dinger.
Genau.
Du benutzt das immer noch so gern?
Ich benutze das immer noch super gern.
Ich auch. Ich habe es auch jetzt letztens wieder
in einem Projekt gehabt
und das war echt
total super.
Wie würdest du denn einen Chat umsetzen?
Ja gut, okay.
Chat, da muss man dann drüber nachdenken,
vielleicht ist es da besser, dann was anderes zu
nehmen. Ja. Könnte schon sein.
Ich meine, man kann es bauen, aber
ob das so viel Spaß macht, weil da ist ja
manchmal vielleicht die Echtzeit dann tatsächlich,
wenn die Echtzeit eine Reaktion hat, irgendwie interessant.
Wenn man jetzt pollen würde, dann
hast du immer so ein bisschen Latenz.
Server-Send-Events, glaube ich,
geht damit. Ja, das geht damit
natürlich auch, aber das ist ja dann
fast das Gleiche, also es ist auf jeden Fall ähnlich wie
WebSockets auch. Also es ist
halt nicht bidirektional, aber du hast halt auch die ganze
Zeit eine stehende Verbindung, die halt die
ganzen anderen komischen Schwierigkeiten
hat, die man dann halt so hat, wie
ja, wie loadbalancen wir das jetzt denn eigentlich?
Was ist denn, wenn ich jetzt irgendwie ein Deployment
mache und ich restarte das Ding?
Was passiert denn da mit der Verbindung?
Ist sie jetzt erstmal weg? Kommt sie wieder?
Kommt sie nicht wieder?
Der Mensch am anderen
Ende des Chats merkt ja einfach nach drei Tagen
irgendwie, dass
keiner mit ihm redet und denkt alle, er stinkt
irgendwie und niemand will mit ihm reden,
tatsächlich ist einfach nur diese Verbindung weg.
Ja, also da kommt man in all diese blöden Fehlerfälle
rein und
das ist halt bei WebSockets und bei
Server-Send-Events so.
Insofern, ich weiß nicht.
Also wenn man es irgendwie ohne sowas machen kann, würde ich es
ohne sowas machen, aber kann sein, dass Chat
eine der wenigen Sachen ist, wo man das halt tatsächlich braucht.
Ja.
Und was ist mit Chat mit dem Server?
Chat mit dem Server ist
Also keine Ahnung, du schickst mit dem Server
eine Frage und nicht einem anderen
Menschen.
Nee, da brauchst du es nicht. Achso, du meinst jetzt so was
wie Chat-GPT, wenn man das implementieren
wollte. Genau, da brauchst du es nicht.
Das geht, Request-Response, super.
Dann wartest du einfach drauf.
Ja, also du kannst halt dann,
du kannst ja auch das anzeigen, was dann zurückkommt
direkt, aber
da brauchst du keine stehende
Verbindung. So gechankt jetzt, oder?
Ja, du kannst einfach
mal da rauskommen, kannst
ja das anzeigen,
das geht.
Genau.
Ja, genau, das ist auch so was.
Genau, dafür braucht man
keine
direktionale
Verbindung oder keine stehende Verbindung.
Okay, dann
5.1 hast du noch.
5.1 Alpha erschienen, genau.
Ich weiß nicht,
ob hier irgendjemand genau die Liste der
Neuigkeiten und so mit dabei hat.
Also ich meine, es dauert auch noch ein Momentchen,
bis das erscheint, aber...
Ist das die erste Alpha?
Ja, also was ich hier schon sehe,
Query-String, super, das habe ich hier halt schon ein paar Mal
selber gebaut. Aber warum gibt es das denn nicht?
Genau, also das Problem
ist, wenn man quasi
ein paar
Dinge hinzufügen
will zu einem Query-String, zum Beispiel, wenn man
irgendeinen Filter angeschaltet hat oder so,
dann ist halt die Frage, okay,
aber da sind jetzt möglicherweise schon Sachen gesetzt
und dann muss man das irgendwie,
wie updatet man das denn?
Und da gibt es jetzt ein Template-Tag für,
wo man halt einfach den Query-String
kriegt und das ist natürlich praktisch.
Ich hatte das Gefühl, dass da viel Quality-of-Life-Sachen
dabei sind. Es sind nicht die großen Game-Changer,
die sind jetzt eher dann für 5.2, glaube ich, geplant.
Später mehr.
Ja, sondern eher Kleinigkeiten,
die einem einfach helfen, besser
und angenehmer zu arbeiten.
Ja, oh, es gibt
Connection-Pool-Support
für Postgres, was dann auch praktisch ist.
Also ich meine, ehrlich gesagt, für meine Sachen
ist es nicht so, also da komme ich
sowieso nie so an die Grenzen, dass ich da wirklich
ein Pool lieber hätte oder so,
sondern es ist alles egal.
Aber wenn man das Problem hat, dann ist es natürlich
doof, wenn man da irgendwie was anderes machen muss.
Ja.
Ja, ja, ja, ja.
Middleware to require authentication
by default. Keine Ahnung, was das ist.
Aber ich würde sagen, über die ganzen Neuigkeiten bei Django,
da können wir doch tatsächlich den Ronny gleich besser fragen,
weil der von Django-Con wahrscheinlich mehr erzählen kann,
als er aus dem 5.1...
Ich glaube, das ist so wahnsinnig...
Ja, genau.
Ist auch nichts Weltbewegendes mehr.
Alles klar, dann, genau, haben wir nur
ein Event, dass es das gibt und
Dann sind wir vielleicht mit der News heute schon ein bisschen durch
oder habt ihr noch irgendwas, was ganz total relevant, wichtig war?
Nicht von meiner Seite.
Okay. Gut.
Dann erzähl doch mal von der DangoCon, lieber Ronny.
Also ich hab, du, also erstmal,
du, eigentlich müsstest du ja von dir selber erzählen, weil du hast ja auch
was gesagt, glaube ich sogar, ne? Genau.
Und was Cooles erzählt und vielleicht fangen wir doch einfach damit an,
dann können wir danach so von allgemeinen Sachen erzählen.
Ja, genau. Also wie gesagt,
ich heiße Ronny, ich arbeite
seit 2012
mit Django. Ich habe damals mit 1.4
angefangen, was
lange, lange her ist.
Damals hatten wir auch noch ein anderes Versionsschema,
also das ist länger her, als es klingt.
Und
bin jetzt seit vielen Jahren
Tech Evangelist in meiner
Firma. Ich arbeite bei der Agentur
Ambient in Köln und
habe da durch die Möglichkeit
mich mit der
Thematik zu beschäftigen und
mich in dem ganzen Django-Backend-Kontext
so ein bisschen auch up-to-date
zu halten und da auch
Sachen zu machen, zum Beispiel auch mal
zu einer Konferenz zu fahren und einen Vortrag zu halten.
Das habe ich dieses Mal das erste Mal gemacht.
Das ist das erste Mal auf einer
echten Konferenz-Stage. Ich war
man könnte vielleicht sagen zum Warmlaufen
letztes Jahr bei dem
Django-Day in Kopenhagen. Das war sehr cool.
Das ist so eine Mini-Konferenz. Das ist so ein Raum
für so 60 bis 70 Leute, würde ich sagen.
Und das ist nur ein Tag.
Und das war sehr nett, sehr familiär und das war so das erste Mal, dass ich irgendwie vor, naja, literally laufender Kamera das gemacht habe.
Das stimmt überhaupt nicht, wir haben dich schon ganz oft live was erzählen hören.
Ja, aber das war nicht mit Livestream zu.
Das ganze Internet konnte zu gucken bei euren Livestreams bei Ambient während der ganzen Zeit, in der letzten Zeit, ja?
Ja, die Django Meetups machen wir nicht. Ach so, das meinst du. Ja, okay.
Ja, doch.
Genau, ich bin nämlich beim Django Meetup Köln, ich organisiere das und da halte ich auch gelegentlich meinen Vortrag, längst nicht mehr so oft wie früher, was glaube ich ein gutes Zeichen ist, das heißt, das Meetup funktioniert, wenn sich Leute finden, die da Spaß dran haben, was vorzutragen.
Genau, und da habe ich einen Vortrag gehalten über mein Package, das ich für Django gemacht habe. Das nennt sich Django Pony Express. Das löst im Endeffekt das Problem, wer schon mal mit Django, also wir machen meistens, so von meinem Job her, machen meistens Business-Applikationen und meistens baut man da relativ viele E-Mails.
Und E-Mails mit Django zu bauen, das geht alles, das funktioniert auch technisch alles sauber, nur die, ich mag diesen Begriff sehr, die Developer Experience ist nicht so richtig gut, weil man da relativ viel Low-Level-Sachen machen muss, vor allem wenn man jetzt nicht nur irgendeine E-Mail rausschicken möchte, sondern halt eine, die modernen Business-Ansprüchen genügt.
Also sprich eine HTML-E-Mail, die ein 50s-Based-Template hat, die entsprechende Heller gesetzt hat, die einen Unsubscribe-Link hat, die irgendwie ansprechend aussieht etc. Und da habe ich mir was überlegt, dass wer Django kennt, kennt ja wahrscheinlich auch Class-Based-Views und ich habe das ganze Thema Class-Based-E-Mails genannt und diese Class-Based-E-Mails habe ich mich sehr an den Class-Based-Views orientiert, um einfach mal eine Lösung zu bauen, wo es halt angenehmer ist.
Dass halt, wenn ich halt eine E-Mail habe, die halt dann HTML-Templates hat oder Inhalt hatten, Plaintext-Part-Inhalt, Übersetzungen, bestimmte Header, bestimmte Variablen, die für das Base-Template benötigt werden, dass ich da halt nicht jedes Mal so riesige Funktionen hin und her kopiere, sondern im Endeffekt halt wirklich nur drei oder vier Zeile habe und die restlichen Sachen halt an einer sinnvollen Stelle gekapselt sind.
Und ein zweites großes Problem, was mich halt auch persönlich immer sehr gestört hat, ist, dass E-Mails, weil die ja irgendwie so ein bisschen eine externe API sind, weil das halt, man schickt die irgendwie raus und die kommen dann quasi vielleicht wieder bei mir an, wenn ich es mir selber schicke, dass wir die nicht so richtig getestet haben, weil es einfach auch mühsam ist.
Und das Django-Test-Framework bringt einem da so ein paar Tools mit, aber die sind alle so ein bisschen versteckt. Und da habe ich dann so einen Wrapper gebaut, der auch so ein bisschen, dass man diese E-Mail-Outbox, wenn man E-Mails in einem Test verschickt, dann landen die in so einer Liste, in einer Outbox, werden die gesammelt, dass sie nicht aus Versehen rausgeschickt werden an irgendwen, dass man auf diese Liste so ein bisschen wie in einem Query-Set zugreifen kann.
Also man kann nach Subject, nach Inhalt filtern, man kann gewisse Assertions machen, ob zum Beispiel in beiden Content-Parts, es gibt ja mehr als nur HTML und Plaintext, ob in den Context-Parts da bestimmte Dinge drin sind und so weiter. Und da habe ich einen Vortrag drüber gehalten, das hat sehr viel Spaß gemacht, ich war sehr nervös.
Ich war sehr aufgeregt, aber es hat sehr viel Spaß gemacht tatsächlich. Ich war unendlich viel schneller als bei den Malen, wo ich geübt habe. Das ist glaube ich so eine Sache, das ist man immer, aber ich war wirklich schnell. Ich glaube, ich habe auf 21 Minuten Testzeit 16 Minuten Vortragszeit gehabt.
immer so schnell geredet wie ich.
Ich weiß es nicht. Ich habe mir versucht, extra ein bisschen
Zeit zu lassen, aber
ja, hat so mittelgut funktioniert.
Nichtsdestotrotz auch viel
positives Feedback bekommen und
ist auch tatsächlich nochmal eine ganz andere
Art, auf so einer Konferenz
zu sein. Das war jetzt, glaube ich, meine
fünfte oder sechste DjangoCon mit
ein paar, ich glaube fünfte, mit
zwei Remote wegen Corona
und das ist echt
nochmal ein ganz anderes Gefühl. Also ich finde generell
kann ich das jedem nur ans Herz legen, wäre es noch nicht
gemacht hat, geht mal auf eine Konferenz.
Auf meiner allerersten Django-Con
habe ich halt Unistyle erwartet.
Da steht irgendwer und erzählt was Langweiliges
und dachte, ich gehe eigentlich wegen den Leuten dahin.
Tatsächlich gehe ich auch gerne wegen den Leuten dahin,
jetzt wo ich auch viele kenne, aber die Vorträge
sind auch wirklich gut und wenn man
denkt, dass das halt auch alles auf einem
kleinen Budget läuft, da jetzt keine große Tech-Company
dahinter steht, die da irgendwie Millionen
einfach mal so verschenkt, sondern das alles irgendwie von
von Volonteers
getragen wird und dann
die sich freuen, wenn da halt irgendeine Firma irgendwie
Tausi reinwirft, ist
das schon echt beeindruckend und
genau, da waren echt
coole Sachen dabei.
Das, glaube ich, der
große Game Changer
sind die Background Workers.
Das ist eine von diesen DEP, also so eine
Django, ich weiß gar nicht, was die Abkürzung bedeutet.
Django Enhancement Proposal.
Ah ja, genau. Dieses DEP, ich glaube
14 oder sowas. Die sind auch irgendwie
in letzter Zeit erst wieder entdeckt worden.
Ich glaube, dass es die gibt und
die werden jetzt auch wieder recht populär.
Ich glaube, auch mit den neuen Fellows, Sarah und Natalia.
Und diese Background Work ist im Endeffekt eine Idee,
dass man, wenn man in einem Django-Projekt Asynchrone ...
Ich glaube, da müssen wir gleich noch ein bisschen genauer drauf eingehen,
vielleicht so als Extrathema,
weil da haben wir vielleicht noch ein, zwei coole Links zu.
Deswegen erzähl gerne noch ein bisschen mehr zu deinem Talk über E-Mails,
bevor wir auf die Background-Tasche gehen.
Okay.
Ja, genau.
Also die ...
Ja, was habe ich denn?
Was kann ich dazu noch sagen?
Irgendwie, war das nicht auch irgendwas, wo so ein Architektur-Design-Pattern irgendwie so ein bisschen eine Rolle spielte?
Ne, vielleicht habe ich das auch einfach falsch.
Einfach nur objektorientierte E-Mails quasi.
Genau, und es ist halt einfach ein Wrapper um die relativ low-levelige API, wenn man halt, wie gesagt, ein bisschen aufwendigere E-Mails bauen möchte.
Das macht Sendmail mit ein bisschen Fluff.
Genau.
Weil Sendmail selbst, das erstellt ein Python-E-Mail-Objekt, glaube ich.
Es gibt auch gerade eine große Diskussion,
weil bei Python da scheinbar etwas deprecated wurde.
In der letzten Version.
Und Django noch auf den alten Sachen.
Ich glaube, es wird nicht deprecated,
aber es gibt so etwas Neueres, Cooleres.
Und die Django-Sachen unter der Haube benutzen noch die alten.
Und dann ist gerade viel in Bewegung bezüglich E-Mails.
Interessanterweise, ich bin da ganz aus Versehen
auf diesen Zug aufgesprungen.
direkt eine blöde Anwendungsfrage, wie
verschickt ihr denn E-Mails?
Also tatsächlich, das ist auch
eine Frage, die ich jedes Mal gestellt werde,
wenn ich diesen Vortrag, ich muss gestehen, ich bin an
mehreren Occasions recycelt,
das ist eine Frage, die sehr oft
kommt. Bei mir geht es wirklich
im Endeffekt nur um die Developer
Experience und um die Maintainability.
Also sprich, wie erstelle ich
programmatisch diese E-Mail,
wie stelle ich sicher,
dass da alles drin ist und wie kann ich das nachher
testen. Alles, was danach kommt,
also im Endeffekt, das ist alles
nicht das, wo das Package ansieht.
Also da hört es quasi auf. Also bei den Unit-Tests,
je nachdem, wie man es definiert, ist quasi
dann das Ende und danach kann man halt
dann die E-Mail so verschicken, wie man sie halt
mit Django sonst verschicken möchte. Also ob man da jetzt irgendeinen
Mail-Hawk reinhängt oder irgendein super
abgefahrenes E-Mailing-Cluster hat oder seine
eigene Gmail-Adresse dafür nutzt oder
einfach das bei
SES reinwirft, das ist
nichts, was man im Package versucht zu lösen.
Wie macht ihr das? Wir selbst
nutzen, SES. Das ist
von Amazon. Ich glaube, das gibt's
aber auch in, also ich glaube, das ist ein Standard
sogar. Ich bin nicht ganz sicher. Ich glaube, Amazon hat ja viele von diesen
Standards definiert.
Und das ist ein Service, der ist
halt sehr günstig und sehr leistungsfähig.
Ich habe für ein
Privatprojekt, ich engagiere mich da
für Kinder in Bolivien,
haben wir früher
unseren Spendern und Interessenten
so einen Jahresbericht
per PDF geschickt, das damals
noch, bevor wir HTML-E-Mails hatten.
Und diese PDFs, das war dann immer so mit den Bildern, auch wenn man die dann runtergerechnet hat, war immer so 500, 800 Kilo bei, das ist schon relativ groß für eine E-Mail. Und unsere alten Mail-Server sind regelmäßig da irgendwie abgekackt, hängen geblieben, mühsam. Dann habe ich irgendwann auf SCS umgestellt. Alle E-Mails zu versenden kostet dann vielleicht ein Euro oder zwei, ich weiß es nicht genau. Und das läuft halt einfach. Also du kannst dir eine beliebige Menge von E-Mails geben und die kommen halt an. Das ist halt sehr, sehr angenehm.
Genau. Ja und tatsächlich, eine Sache kann ich dazu sagen, was mich auch sehr gefreut hat, ich habe ja wie gesagt für den Vortrag auf der Con ein gutes Feedback bekommen, habe mich da mit ein paar Leuten unterhalten und habe ja noch ein paar Tipps bekommen, weil ich halt in der Conclusion auch überlegt habe, was da Sachen drin sind, die meiner Meinung nach auch gut ins Django Core, also in das Framework passen würden und dass wir dort, dass ich mich freuen würde halt was zu contributen, aber ich halt bis jetzt halt noch nicht so die richtigen Sachen hatte, es hat nie richtig funktioniert.
Da habe ich ein paar Tipps bekommen, wie ich das mache. Es gibt nämlich ein Django-Forum, das wird es auch gerade noch ein bisschen, die versuchen gerade so ein bisschen die Kommunikation da auch drin zu centralisieren und da dann einfach meine Idee, also mit etwas kleinem Anliegen.
fangen, zum Beispiel dieser Testing-Helper,
dass man halt quasi
durch einen, also
dass man alle textbasierten
Medieninhalte einer E-Mail, also
in den meisten Fällen HTML und Plaintext,
wirklich einfach gucken kann, ist
dieser String da drin, also zum Beispiel
weiß ich nicht, ist, da steht da drin
lieber Jochen als Anrede oder steht da
drin Auftragsbestätigung oder ist da diese
Auftragsnummer drin, solche Geschichten.
Und diesen Helper haben wir
dann in einem Forum-Thread ausdiskutiert.
Die Lösung, da haben sich auch sehr viele Leute beteiligt,
die Lösung, die rausgekommen ist, ist viel besser als das, was ich mir
alleine überlegt hatte. Es war viel
weniger zu implementieren, lustigerweise auch,
was man alleine gemacht hat.
Es gibt diesen schönen Spruch,
Weeks of Programming can save hours of
Planning, das war wieder sehr wahr.
Und genau, dann
ist vor zwei Wochen, glaube ich,
dann das auch gemerged
worden in Django Core. Also in 5.2
habe ich meinen ersten Commit, was mich sehr freut,
jetzt nach zwölf Jahren.
Cool. Vielen Dank.
Genau.
Ja, das klingt cool. Also ja, ich muss es eigentlich auch mal ausprobieren. Ich hatte das zwischendurch mal so angeguckt, aber nicht dann angefasst, weil die E-Mail-Lösung bei mir war schon fertig und ich hätte hier alles umbauen müssen.
Ja, ich kenne das.
Und ja, aber eigentlich für das Template wäre es eigentlich cool, das drin zu haben, weil das klingt danach, als müsste man das an verschiedenen Stellen schön benutzen können, weil halt auch, wie du gesagt hast, diese ganzen Features, Templates per HTML und so weiter, sehr gerne genutzt werden.
Tatsächlich ein Feature, was ich persönlich sehr mag, einfach so ein Convenience-Feature, de facto interessiert die wenigsten Leute wirklich der Plaintext-Part, weil die normalen, die modernen E-Mail-Clients oder die Web-basierten Clients den eh nicht anzeigen.
Das heißt, die einzigen Arten, wo man das sieht, ist, wenn man so ein E-Mail-Client hat, dann geht so ein Pop-up auf, das nimmt meistens den Plaintext-Part oder wenn halt irgendjemand auf seinem Linux-1980-Konsolen-basierten E-Mail-Programm noch sitzt, da gibt es auch so ein paar Spezies, die das machen.
Aber ansonsten sieht es halt niemand. Und ich habe mir mit einem externen Package, als Default rendert der einfach das HTML-Template als Plaintext und tauscht dann halt die Tabellen durch Pipes und sowas. Die Struktur ist nicht schön, es funktioniert, auch Links und sowas kriegt der hin. Also das kriegt dann quasi wieder der Client dann hin, der das dann auch trotzdem, auch Plaintext meistens zumindest, dann wieder irgendwie interpretiert.
Und das ist sehr angenehm, weil dann hat man keine doppelten Templates mehr und das ist natürlich schon ein Problem, dass man durch diese doppelten Inhalte, wie zum Beispiel bei uns in einem Projekt, wo wir gearbeitet haben, hatten wir bestimmt 50 verschiedene E-Mails, alles mögliche, um halt den Kunden zu informieren, was so mit seinen Dingen passiert ist und da wurde ständig vergessen, eine von beiden Teilen anzupassen.
Das kann man natürlich in gewissen Maßen durch diesen Testhelper lösen, dass man das einfach unit testet. Nichtsdestotrotz, wenn es ein Rechtschreibfehler oder sowas ist, hat man vielleicht darauf gerade nicht geschaut. Das war ein ständiger Pain und das kann man sehr gut damit halt einfach erschlagen und löst das Problem damit. Das ist sehr angenehm.
Sehr gut. Und du hast gesagt, macht auch sowas dann wie Opt-out-Links oder für E-Mail-Newsletter oder sowas dann direkt mit drin? Ist das da in einem Package drin?
Also das Package nicht, die Idee ist quasi, dass man, also diese, dass man, also ich biete quasi, also das Package, nicht ich, nicht ich persönlich, biete so eine Basisklasse und wenn man von dieser Basisklasse erbt, dann kann man halt dann eine E-Mail definieren, kann ein paar Attribute setzen, zum Beispiel das Subject setzen, das Template setzen, gegebenenfalls noch Kontextvariable mitgeben, zum Beispiel den Auftrag oder den Link oder irgendwas, was halt der Inhalt der E-Mail ist.
Jetzt hat man aber natürlich oft einfach so, also die E-Mails, die man schickt aus dem System, sollen ja irgendwie einheitlich sein. Wie auch bei einer Webseite hättest du ein Basis-Template. Du hast da das Logo oben drin, du hast da vielleicht eine generelle Anrede, du hast ein Footer, wo ein paar legale Sachen drinstehen, wo vielleicht ein Unsubscribe-Link drin ist und diese ganzen Sachen, die ganzen Informationen, die man dafür braucht, das sind auch die dynamischen Sachen.
Zum Beispiel, wenn man sagt, der Unsubscribe-Link enthält ein Hash oder sowas, dass der Nutzer identifiziert werden kann, der das draufgeklickt hat und solche Geschichten. Wenn man da einfach von der meiner Pony Express Basisklasse ableitet, eine eigene Basisklasse macht, dort dann halt die zum Beispiel die Get-Context-Data, wer Django kennt, weiß, was ich meine, überschreibt, dann kann man da halt einmal die ganzen Sachen definieren oder zum Beispiel, dass man Subject-Prefix hat.
Ich persönlich finde, es sieht immer schön professionell aus, wenn alle E-Mails, die vom System kommen, halt irgendwie geprefixed sind oder zum Beispiel dann irgendwie meinwebshop.de minus und dann halt Account erstellt, Passwort reset und was auch immer und diese Sachen kann man einmal definieren und jede E-Mail, die man dann weiter erstellt, leitet dann halt von dieser eigenen Klasse ab und das, ich meine, das ist halt ganz normale Objektorientierung, das hat jetzt nichts mit dem Pony Express zu tun, aber das ist halt, das macht es sehr angenehm und führt auch dazu, dass die eigentlichen E-Mails, die ich am Schluss dann, wo ich dann auch die N, die N-te,
dokumentieren muss, dass das wirklich dann meistens halt nur zwei oder drei Zeilen Code sind. Was es natürlich auch wieder sehr angenehm macht, neue E-Mails hinzuzufügen. Genau.
Cool, cool. Hast du da auch so White-Label-Templates dabei, die quasi gar nichts vorgeben, aber die es schon gibt und die man einfach benutzen kann?
Also ich tatsächlich, wenn ich das mache, ich fange immer an mit einer Google-Suche nach responsive E-Mail-Template, da lande ich immer bei dem gleichen GitHub-Repo, das es schon seit, ich glaube, 2015 oder sowas gibt. Das ist immer noch überraschend gut und das funktioniert auch.
Das müssen wir unbedingt in die Show noch stellen.
Das ist super simpel, es tut es aber irgendwie, ich weiß auch nicht genau warum, aber wenn man sich halt da ein paar Regeln hält, je nachdem wie alte E-Mail-Clients man unterstützen möchte, die früheren Outlook-Versionen sind ja ziemlich wild, die dann unter der Haube so ein Indexbrowser 5 oder sowas haben, das tut dann schon weh, wenn man die unterstützen möchte, aber wie gesagt, kommt halt auch immer dann drauf an, wie wichtig das dann ist, also vielleicht akzeptiert, wie halt auch mit Browsern, vielleicht ist es auch einfach okay, wenn dann der eine, der halt noch den Indexbrowser 11 nutzt, wenn das dann die Webseite halt nicht perfekt aussieht.
Von daher, das ist auch wie gesagt ein Thema, auf das ich mich gar nicht fokussiert habe, weil ich versucht habe, nicht zu viele Probleme in einem zu lösen. Ich habe selbst überlegt, ob ich diese Sache mit den Class-Based-E-Mails und die Sache mit der Testsuit, ob ich die auseinanderziehen soll, weil es ja im Endeffekt die Testsuit einen eigenständigen Nutzen hat, auch wenn ich keine Class-Based-E-Mails verwende.
Es ist einfach nur ein Django-Ding und man soll ja Packages eigentlich immer so bauen, dass die nach Möglichkeit genau ein Problem lösen, weil es auch dann einfacher zu verkaufen, einfacher zu verstehen ist. Von daher habe ich mich auch entschieden, dann da nicht noch weitere Dinge reinzubauen und auch persönlich, weil ich da halt auch nicht so die Pain-Points hatte.
Also hast du eh schon trotzdem mal Copy-Paste, musstest aber erst nicht bereitstellen mit dem Package, okay, verstehe.
Genau.
Ja, klingt gut.
Aber jetzt kommen wir tatsächlich, glaube ich,
dann zu Django Tasks, weil, wenn man
ihm es verschicken möchte, möchte man das ja
wahrscheinlich nicht sequenziell.
Genau, nicht im Main Thread.
Und genau,
da gibt es
ein neues Konzept, wie gesagt, das
nennt sich Background Workers, das lebt aktuell in einem
Package namens Django-Tasks.
Da muss man aufpassen, es gibt ganz viele, die ähnlich
klingen. Django-Background-Tasks,
Ja, Background-Task-Manager.
Genau, auf jeden Fall dieses Django-Task-Package.
Das ist von Jake Howard.
Der hat das jetzt relativ schnell zusammengenagelt.
Das ist echt erstaunlich.
Der freut sich auf jeden Fall über ...
Doch, das ist nicht Django-Background-Task.
Ja, ich merke schon.
Ich merke schon, ich google hier.
Der freut sich auf jeden Fall immer über Leute,
die das ausprobieren.
Also wer von euch Interesse an Django hat,
möge das gerne anschauen.
Jetzt muss ich auch noch einen Satz sagen,
was das überhaupt ist.
Ja.
Genau.
Also in den meisten Projekten, wenn man irgendwas asynchron machen möchte, da meine ich jetzt gar nicht dieses in ganzem Sinne relativ moderne Async, sondern einfach, ich möchte irgendwelche Prozesse nachgelagert machen, zum Beispiel irgendeine große Berechnung machen, irgendeinen Cache befüllen oder halt auch eine E-Mail schicken, weil ich möchte ja mit dem, E-Mail ist ja, ich muss ja mit der externen API kommunizieren, um die E-Mail zu versenden, da möchte ich ja im Optimalfall nicht meinen externen Thread blockieren, äh, meinen Main Thread blockieren.
Genau, deshalb gibt es in jedem Projekt, in dem ich gearbeitet habe, irgendeine Art von asynchronem Processing, meistens in der Form von Celery, das ist in der Python-Welt sehr bekannt, in der Django-Welt.
Sehr gehasst und gefürchtet.
Ja. Gibt es Django Q oder Q2? Ist jetzt aufgekommen, das ist so eine leichtgewichtigere Alternative, weil das Hauptproblem ist, dass Celery erzwingt, dass man irgendeinen Broker dazwischen stellt, der als Message-Queue dient.
Man kann das auch so konfigurieren, dass der direkt die Datenbank nimmt.
Oder der hat eine lokale Datei, in der er irgendwas reinschreiben kann und macht irgendeine SQLite noch extra auf.
Okay, das weiß ich, ja, aber ich glaube, man muss es nicht unbedingt, also es ist üblich, ja.
Und es ist auch, also ich habe das mehrfach schon gesucht und für die Result Backends, also bei Celery, wenn quasi um die Ergebnisse zu speichern und das im Endeffekt so eine Art Log, was passiert ist, dafür geht das, das ist relativ einfach, aber für den Broker selbst bin ich zumindest immer damit gescheitert.
Ich war tatsächlich nie so viel investiert darin. Auf jeden Fall für die allermeisten Cases ist es halt einfach harter Overkill, wenn man da halt irgendeine Postgres oder MariaDB hat. Die kann in den, zum Beispiel bei uns in den meisten Fällen, kann die paar hundert Tasks, die am Tag laufen, problemlos abfrühstücken, ohne dass sie da irgendwie in Verlegenheiten kommen.
und selbst bei ein paar tausend Tasks ist es immer noch
kein Problem. Vor allem, wenn man dann
vielleicht auch sagt, dass
die, dass die ein großer Task vielleicht auch eher
nachts läuft für irgendwelche Sachen,
dann, da ich auch keine Userlast habe
und das wird allgemein
sehr stark als Overkill angesehen. Dazu,
wie Dominik gerade schon gesagt hat, viele Leute fürchten
auf Celery für, aus verschiedenen
Gründen.
Das wird oft kaputt auch eingestellt, verhält sich komisch.
Aber vielleicht, also ist die Frage, ob es an Celery liegt oder
daran, dass Icing halt ein bisschen schwieriger ist?
Also da würde ich
gerne nochmal kurz eine Begriffsklärung machen, weil
viele sagen ja, Async,
und ich höre auch immer, wenn von
Async die Rede ist, dass dann Leute sagen so,
das merke ich
dann irgendwie nach einer gewissen Zeit, dass Leute eigentlich
sowas wie Celery meinen.
Aber das hat ja jetzt zum Beispiel mit
Async.io oder so
damit überhaupt gar nichts zu tun, das ist etwas ganz anderes.
Ja, also Celery ist ein eigener Worker-Prozess,
wenn ich mich nicht verstehe, der halt einfach Taster
arbeitet zu einer bestimmten Zeit, die halt in der Liste stehen
und dann also diese Queue
leert. Ja, du hast so eine Anzahl von Workern
und du hast halt irgendwie
genau
ein Ding, das halt eventuell auf so einer
Queue drauf sitzt und dann verteilt es halt Jobs an
diese Worker und die machen dann halt
Dinge und schreiben ihre Resultate wieder
irgendwo hin.
Ich glaube, warum die Leute denken, dass es Essing ist,
weil das halt meistens, wie schon gesagt, nicht im
Main-Prozess läuft, obwohl man das auch machen kann. Du kannst ja
mit Django mitstarten oder so.
Die Frage ist auch da, was das halt heißt.
Also weil, Jochen weiß das
bestimmt besser, weil es ja irgendwie verschiedene Event-Queues
die man nutzen kann, G-Event oder Event
oder irgendwas? Nee, nee, gar nicht. Damit hat es
überhaupt nichts zu tun. Also mit G-Event oder sowas
hat es überhaupt nichts zu tun. G-Event ist sowas wie Async.io
ganz anderes. Aber kann man machen, also wenn man das
mit der Django selber macht, dann muss man sich überlegen, welche
da benutzt wird. Ja, aber nichts, also
nicht sowas wie G-Event oder auch nicht sowas wie Async.io
gar nicht. Also das ist einfach was ganz anderes.
Das ist auch nicht
eine Geschichte, die im gleichen Prozess normalerweise stattfindet,
sondern du hast halt tatsächlich andere Prozesse.
Ja, wenn man die hat, genau,
wenn man die anderen Prozesse hat, dann schon. Anders
geht es nicht.
okay. Also, genau.
Das geht anders, jedenfalls nicht, dass ich
wüsste, dass das irgendwie anders gehen würde, weil
wie soll das funktionieren, wenn du halt jetzt
irgendwie, keine Ahnung,
also, nehmen wir an, du
stößt halt an einem Request,
also du hast halt irgendwie einen Button, da steht drauf, send email,
drückst du auf email
und wie soll das jetzt gehen, dass
dann eine email,
ja, so vielleicht geht es tatsächlich irgendwie,
aber das ist alles sehr hässlich, also
ne, du willst eigentlich
ein Task dafür schrauben, der ganz woanders ist.
Du hast recht, du willst das auf jeden Fall.
Da würde ich dir auf jeden Fall zustimmen.
Definitiv. Ja, aber diese beiden Dinge haben eigentlich
nichts miteinander zu tun. Auch wenn man das eine für das andere
vielleicht so halb irgendwie verwenden kann, aber
nee, das ist eigentlich was ganz anderes.
Wie gesagt, es ist halt,
es ist halt, also die, wenn du dir,
wenn du quasi auf den Main Thread schaust,
dann läuft es halt irgendwie nicht da drin.
Von daher liegt es halt nahe, das irgendwie
asynchron zu nennen. Auch wenn das mit dem
Async, mit dem Python Async natürlich nichts zu tun
hat, technisch. Ja.
Genau, aber es läuft halt nicht irgendwie Async oder in einem anderen Thread, sondern es läuft in einem anderen Prozess. Also hat überhaupt gar nichts mehr mit dem Ding zu tun, mit dem der Interpreter da läuft.
Genau und insgesamt das Salary Setup ist halt auch relativ, also da schießt man wirklich schon mit sehr großen Kanonen, weil ja meistens man dann mehrere Worker hat, man hat einen Beat für Scheduling, also der im Endeffekt diesen Contab dann ersetzt, dann gibt es noch dieses Monitoring Tool Flower, was so mittelgut funktioniert und eher schlecht als recht meiner Meinung nach gewartet ist.
Nichtsdestotrotz, wenn man mal irgendwie reingucken möchte, hilft es schon. Dazu, das kommt halt noch, dass man wie gesagt meistens halt dann diesen Message Broker braucht, der halt dann meistens ein Redis oder ein RabbitMQ oder irgendein Derivat davon ist. Und das ist halt für viele Projekte, vor allem am Anfang, ist das halt ein enormer Setup-Aufwand. Wer das erste Mal in seinem Leben Celery einrichten muss, der wird daran keinen Spaß haben.
Nicht, weil, wenn du halt zum Beispiel auf das redest, wo du sonst nichts anderes benutzt oder sowas, das läuft halt halt die ganze Zeit rum.
Genau, und es bläht das Setup halt enorm auf und es ist jetzt halt, seit scheinbar auch Jahren ist es halt irgendwie allen bewusst, dass es halt schon cool wäre, wenn Django da selber was könnte und man halt eben nicht mit, da, ne, mit Celery kommen muss.
Wie gesagt, die Popularität von Django Q oder Q2, wie der Nachfolger davon heißt, der ist ja tatsächlich jetzt auch nicht aus der Welt, weil der im Endeffekt wirklich sehr, sehr leichtgewichtig einfach nur halt Dinge irgendwann außerhalb in einem anderen Prozess abarbeitet.
Und die Idee von Jack Howard ist jetzt, das wirklich in Django zu integrieren. Er hat erstmal ein Package gemacht, wie man das halt optimalerweise auch so macht, dass Leute es auch separat testen können. Und das Ganze hat er vorgestellt. Das war, ich weiß nicht, ob es wirklich eine Keynote war, aber es war auf jeden Fall de facto eine Keynote. Ich glaube, das war das, wo die Leute am meisten und am heißesten drauf waren.
Und das ist sehr spannend, weil ich tatsächlich auch bei mir in meinen diversen Projekten glaube ich auch einfach aktiv zurückbauen würde, weil ich einfach happy damit wäre und aus der Salary Setup in den allermeisten Fällen verzichten kann.
Es gibt jetzt wirklich Cases, wo man sagt, okay, wir machen so viele, wir machen so komplizierte Dinge, das macht natürlich Sinn, da was Explizites zu haben, nur wie immer, es macht halt vor allem, wenn man jetzt auf ein Budget achtet, macht das natürlich schon Sinn, da erst mal mit einer einfachen Lösung anzufangen, einer einfachen, soliden Lösung.
Billig und schnell rächt sich meistens irgendwann. Genau. Was übrigens auch ganz interessant war, ich habe der Talk von Carlton Gibson, ging im Endeffekt um mal wieder HTMX ist super und mit Alpine.js kann man zusammen coole Dinge machen und sein Treiber davon war, dass er halt sagt, dass jetzt, wo wir in einer Zeit leben, wo die Zinsen seit langer Zeit wieder ein bisschen höher sind, Venture Capital deutlich seltener geworden ist und in deutlich kleinere Mengen vergeben wird.
Und dass deshalb dieses, ich habe ein Startup und ich möchte irgendwas ausprobieren, dass die einfach mit viel weniger Geld die Sachen bauen müssen. Und das ist halt nicht so, wir bauen jetzt die in der perfekten Welt, sondern es muss schnell gehen. Es muss irgendwie solide sein, aber es muss halt vor allem effizient sein. Und das hat deshalb nochmal den HTMX Tech verkauft, was ich persönlich auch absolut unterschreiben würde. Und das Interessante ist halt, dass ich zum Beispiel habe jetzt noch nie, ich meine, ich habe an ein paar Startup-Projekten mitgearbeitet, aber jetzt nicht mit riesigem Venture Capital. Das ist halt eher so in deutschen Scales gewesen.
Ja, genau, da gibt es das auch nicht so.
Und es war immer für uns im Agenturbusiness, wir haben halt ein Budget und das ist eigentlich eher tendenziell zu klein als zu groß.
Ja, wie immer.
Und das ist einfach, das ist interessant, weil das, ja, ich meine, wird ihm vorher auch schon klar gewesen sein, aber das nochmal so auf den Punkt zu bringen und dann zu sagen, ja, genauso sehe ich das auch, weil ja, natürlich kannst du, wenn du mit React oder Vue kannst du ausgefallene Referendums bauen, kannst du mehr Dinge tun.
Die Frage ist, brauchst du das
und schaffst du das in dem Geld, das du hast?
Und das, finde ich, ist halt
so der spannende USP da dran.
Klar, wenn man erstmal seine
komplette Applikation in HTMX ohne API gebaut hat
und man kommt ein und sagt, ich möchte das jetzt alles anders
haben, das ist natürlich auch nochmal teuer.
Also ich glaube, man muss da auch ein bisschen in die
also nicht nur sagen, wie viel Geld haben wir jetzt, sondern wo geht
das Ganze hin? Nichtsdestotrotz
persönlich finde ich das auch sehr spannend.
Der Talk war auch sehr cool und sehr
energetisch, wie Carlton Gibson halt immer so ist.
Genau,
War echt super spannend.
Ich glaube,
dieses Django-Template-Partials kommt halt
auch irgendwie jetzt, ich weiß es rein,
ich weiß nicht, ob das schon bei 5.1 war,
oder doch eher 5.2, wahrscheinlich eher 5.2,
nehme ich mal an.
Oder hat er auch über
dieses Neapolitan-Ring
gesprochen, was er da...
Genau. Das ist ja auch so ein...
Neue Quad-Views oder so? Ja, genau.
Also das dreht sich alles um diese Idee
des Locality of
Behavior. Carlton Gibson hat jetzt
vor nicht allzu langer Zeit einen
Newsletter angefangen, Stack Report heißt
der, wo er einmal im Monat sehr
ausführlich zu einem Thema schreibt. Ich habe den
abonniert, das kostet glaube ich irgendwie 5 Euro
oder sowas. Bis jetzt hat es sich,
also ich glaube es gibt es erst seit 2 oder 3 Monaten,
bis jetzt hat es sich gelohnt, also ich mache da gerne
auch nochmal Werbung für ihn, unbezahlt.
Das finde ich echt cool.
Also es war echt interessant,
er hat jetzt über diverse Dinge da
geschrieben und das hat in dem aktuellen von diesem
Monat ging es halt um Locality of Behavior
und er versucht halt im Endeffekt
das Konzept zu verkaufen, also er sagt halt,
dass wenn halt alles, was du brauchst, in einer
Datei steht, ist es halt einfacher zu verstehen
und er argumentiert
nicht, dass man alle guten
Principles, die man gelernt hat, sofort wegwirft,
sondern dass man halt dieses Premature Optimizing
aufhört, dass man sagt, okay,
ich fange jetzt schon mit, weiß ich nicht,
die, die, die an und mache das alles perfekt in
vielen Dateien, ein Neueinsteiger in dem Projekt
hat keine Chance zu verstehen, was eigentlich
passiert, sondern fangt erstmal klein an
und refactored, wenn ihr es wirklich braucht.
Weil viel von dem, ah ja, ich brauch das
nochmal, ich mach das mal irgendwie woanders hin,
kommt dann nachher mit, naja, ist doch
irgendwie anders geworden, war doch nicht so, wie ich es mir
gedacht habe. Und dann hat man halt immer diese doppelte
Refactoring-Schleife. Und dieses
Django Template Views ist halt die Idee,
Django Template Partials,
sorry, Partials,
dass man halt wirklich sagen kann, okay,
diesen Block kann ich jetzt mit HTMLX
neu rendern lassen, der ist aber trotzdem noch
in der großen Datei und ich muss es nicht zerpflücken,
wie man es halt vorher, also Stand jetzt mit
Vanilla Django macht
und diese Neapolitan
Crudviews ist auch die Idee, dass du halt wirklich mehr
Sachen an einer Stelle zusammen
hast. Dass man im Grunde eine Klasse hat, wo die
ganzen, also GetPost und sonst wie Dinge,
die da passieren, halt alle drin sind.
Ich persönlich
finde, dass Locality of Behaviour ist, glaube ich,
eine gute Sache. Ich meine, das geht auch so ein bisschen nach
Yagni, also You Ain't Gonna Need It,
dass man halt nicht, dass man erstmal überlegt,
so muss ich jetzt wirklich anfangen,
alles so hoch zu skalieren, wie es unbedingt
notwendig ist. Nichtsdestotrotz,
wenn ich halt in einem Projekt, wenn ich weiß, ein Projekt
wird eine gewisse Größe erreichen,
die Dinge zu tun, die ich jetzt schon
weiß, die sinnvoll sind,
glaube ich, dass man sich da dann andererseits auch
wieder ein paar Refactoring-Zyklen spart.
Aber ich glaube, generell ist man schon sehr
prone, als Entwickler over zu
ingenieren und ich glaube, das sich im Kopf zu behalten,
so muss ich das jetzt wirklich tun.
So ein bisschen so ein Trade-off mit KISS oder so was
und schon simpel und dass du irgendwie tatsächlich
versuchst, vielleicht, also was ich
zum Beispiel finde, ist, dass wenn halt zu viele Sachen in einer
Datei drinstehen, selbst wenn das irgendwie am Anfang
überblicklich ist, wird es halt auch dann wieder hässlich.
Und wenn eine gute Modulstruktur
darunter liegt einfach, also einfach nur vom
Namespacing her, hilft das fast
am meisten, finde ich.
Was dann auch gar nicht schwer zu verstehen macht,
wenn das halt alles in einem Directory liegt, zum Beispiel,
dann ist das schon vielleicht ein bisschen näher dran. Aber wenn das
Directory dann groß wird, dann ist das wieder ein Problem.
Das ist so, ja.
Oh, ich würde ganz kurz
nur einmal kurz einlaufen
nochmal zu dieser Task-Geschichte,
was ich halt oft sehe, was ich finde,
was man vermeiden sollte,
wenn Leute sowas machen
und das halt irgendwie, weil oft
macht man das dann ja, man braucht
es schon meistens, aber dann doch nicht
irgendwie so dauernd, dass man da,
dass alle Leute da irgendwie
viel Erfahrung mit hätten.
Und was ich jetzt schon häufiger gesehen
habe und was in der Praxis dann so
zusätzlich zu diesem ganzen
Infrastrukturding auch nochmal ordentlich Schmerzen macht,
ist halt, wenn Leute anfangen,
irgendwie so ganz Kaskaden von Tasks
irgendwie zu schreiben,
so gerade bei Celery ist das dann halt auch sehr
einfach und dann hat man da Abhängigkeiten
inzwischen und dann, und Leuten
ist gar nicht so bewusst, dass es bedeutet, ja,
es geht jedes Mal über eine Prozessgrenze, dann wird da
irgendwie wieder irgendwas wieder realisiert, dann muss der
Kanzlerrahmen wieder so heraussehlich realisiert werden
und dann geht es irgendwo zwischendurch schief und dann hast du halt
irgendwie so ein
explodiertes Gedärm irgendwie, was da rumliegt
und das ist halt so schön.
Und also was ich nur empfehlen kann,
ist, man macht halt eine Funktion oder
so eine Methode an irgendeinem Modell oder so
wo man halt das, was man tun möchte, halt reinschreibt
und dann testet man das ganz normal, synchron,
irgendwie wie man
Sachen halt so testet und dann
sagt man in einem
Celery-Task eigentlich nur, okay, man ruft halt dieses Ding
auf, fertig. Wie man
auch im Vue schreiben würde, möglichst schlank
und eigentlich nur die Dinge
komponieren, denn wirklich da implementieren.
Ja, und keine Logik
in die Tasks packen, sondern
von den Tasks, also in dem eigentlichen
Celery-Task immer nur irgendwie Logik,
die irgendwo anders ist, aufrufen.
Aber wenn du halt Logik hast, oder am besten Logik verteilt
über mehrere Tasks, dann passieren
scharröckelige Dinge unter Umständen.
Und ja. Absolut.
Genau. Das war nur so ein kurzer
Einwurf. Ja.
Es gab da noch so ein tolles
Thread zu im Chaos Social,
den du auch, wo du den Link vorhin geteilt hast,
der sehr, sehr interessant war.
Zu dem, ja. Einige coole Leute.
Unter anderem Carlton Gibson selber und
der Hüneck und so. Ja, Hüneck. Ja, genau.
Und diverse Leute. Da gab es ein Thread
zu, was braucht man jetzt bei Background-Tasks
eigentlich alles. Ja. Und was sind
da die Anforderungen genau?
Neu geschrieben oder anders implementiert.
Und auch alle haben sich über Celery beschwert aus Gründen.
Ja, ich kann das mal,
genau das Ding verlinke ich auch mal.
Ja, Fediverse ist halt zur Zeit, also wenn
er noch nicht ist, da sind halt
alle. Es steht tatsächlich auf meiner Liste
und ich lese halt immer so ein bisschen mit, aber naja.
Ja, also da ist,
also das fühlt sich an wie Twitter früher,
so ein bisschen Blümchenwiese mäßig.
Weil alle Leute sind,
oder viele der Leute, die man so kennt,
und da und man kann
sich mit denen einfach so unterhalten und so.
Ja, cool. Genau.
Ja,
das ist ein interessantes Thema.
Genau.
Was ich auch interessant fand,
ich habe mit auf der Konferenz
noch ein Wort mit dem
Creator da gewechselt
und er meinte auch, dass
früher wurde, also wenn ich es richtig
verstanden habe, ich will mir jetzt keine Worte in den Mund legen, aber wenn ich es
richtig verstanden habe, meinte er, dass früher bei Django
eher so die Idee war, alles was nach
Chor kommt, muss mehr oder weniger
so die eierlegende Wollmilchsau
110%-Lösung sein, weil das ist ja
Django, das muss ja so. Und jetzt
war halt die Idee wirklich zu sagen, naja, aber lass uns
doch erst mal mit was anfangen, was halt alleine
steht, also dieser MVP-Gedanke.
Natürlich kann man noch 400 Sachen nach
und dazu bauen, aber braucht man
die wirklich? Will das
die Crowd so?
Und dass die jetzt wirklich anfangen und versuchen,
ja,
also wirklich mit einem kleinen
Inkrement zu shippen, dass halt
stehen kann, das laufen kann
und alles, was halt danach kommt, einfach
zu gucken, wie reagieren die Leute,
was für Sachen werden wirklich angefragt, das finde ich halt
sehr interessant, weil ich glaube, das ist einfach so ein generelles
Ding, wenn man irgendwie in der Softwareentwicklung ist,
dieser MVP-Gedanke ist so, so,
so zentral und da kann man
so viel falsch machen und so viel Geld und Projekte
und Chaos verlieren,
wenn man halt nicht dem MVP
denkt, weil
schöner geht halt immer und
ja,
genau.
Genau, bei Ruby on Rails
ist halt auch diese
Background-House-Geschichte schon seit Ewigkeiten drin
und das war halt mal eine
der Geschichten, die in Django halt, ja, wo man
da halt irgendwie dann immer sagen musste,
ja, nimm mal Terry, ja, es tut weh,
nimm's halt trotzdem, das ist das, was es
gibt.
Ja, und
wenn sich das jetzt ändert, dann ist auf jeden Fall
ein Pain-Point irgendwie auch weniger.
Die haben gesagt, dass wenn es
gut läuft, landet das in 5.2, du
weißt, wann 5.2 rauskommt, hattest du gesagt?
Äh, April hatte, ja.
Genau.
Dann wird dann neben meinem kleinen
Testhelper das zweite große Ding,
während du dann die Background hast.
Oh, sehr gut, sehr gut.
Ähm,
genau.
Ja, also, HTMX war diesmal auf der
JungleCon also auch quasi wieder so ein,
ist ja die letzten Male eigentlich immer ein großes Thema gewesen.
Genau. Ja, ich meine,
HTMX ist halt, ist halt
im Endeffekt die Silver Bullet, mit der
sehr, sehr viele Leute dann HTMX
vermeiden können,
was natürlich so ein bisschen
ein Gänsefüßchen ist, weil man natürlich immer noch ein bisschen
JavaScript braucht und das auch sehr viel mit JavaScript geschrieben ist.
Nichtsdestotrotz
vermeidet das halt, dass man in Projekten
JavaScript verwenden muss,
was natürlich für viele tendenziell eher
Backendler, wie ja Django aktuell
verwendet wird, weil es ja auch ein sehr data-driven Framework ist.
Das ist
natürlich sehr angenehm, da zähle ich mich auch dazu.
Ich habe es auch irgendwie nie geschafft,
mich ernsthaft mit einem
JavaScript-Framework zu beschäftigen und
ich bin
auch in meinem Beruf immer wieder damit konfrontiert,
bei den Entscheidungen, wenn man
ein neues Projekt startet, was nehmen wir jetzt?
Wir haben uns jetzt tatsächlich bei dem letzten Projekt, das gestartet ist,
auch aktiv für HTMX entschieden.
Auch mit einem Team, die tendenziell
eher JavaScript-Front-Endy
sind.
Ja, das ist natürlich interessant.
Und weil wir einfach auch gesagt haben,
das Projekt ist halt
eine ganz klassische Backend-Applikation. Man hat viele
Listen, man hat viele Crud-Views. Es gibt
zwei, drei, vier Sachen, die so ein bisschen
ausgefallen sind, aber auch nicht so wirklich.
Also da hat man mal so ein Drag-and-Drop-Element
oder sowas. Und wir sind
einfach der Meinung, dass
das dafür halt HTMX wirklich
gut funktioniert, weil das ist das, was Django wirklich
gut kann.
Und das Projekt
ist es auch nicht etwas, wo man sagt, das ist jetzt
irgendwie, wenn
die Firma durch die Decke geht, dann so und
so, sondern das wird immer eine Backend-Applikation
bleiben. Logischerweise wird die wachsen, wenn
die Firma wächst, etc.
Aber das wirkte einfach nach dem
nach dem perfekten Hammer für diesen Nagel.
Was nicht heißt, dass wenn man
jetzt sagt, ich möchte jetzt keine Ahnung, das
nächste Instagram oder sowas bauen,
dass das vielleicht, wenn man schon die Kohle dafür hat am Anfang,
dass das vielleicht nicht unbedingt
die beste Wahl ist. Geht wahrscheinlich auch
alles trotzdem, aber
ich glaube umso mehr, sag ich mal,
wirkliche Endnutzer, also jetzt nicht Mitarbeiter
der Firma oder Administratoren, sondern wirkliche Endnutzer
man auf der Plattform hat, wahrscheinlich schwingt da
dann immer so die Notwendigkeit für
ein richtiges, volles Frontend-Framework,
wo man das ja auch in Gänzefüßen sehen muss, React und
Vue sind ja auch keine Frontend-Libraries,
schwingt dann doch eher so das
Pendel in diese Richtung.
Und ich glaube, diese Frage kann man halt
wie jede einzelne Tech-Frage damit
beantworten. Es kommt drauf an.
Nichtsdestotrotz wird das natürlich
hart gefeiert in der Community, weil, wie das
auch bei mir so ist, das ist es halt, ich meine,
ich bin seit zwölf Jahren dabei, das erste
Mal, dass man, dass ich
jetzt wirklich ein Werkzeug
bekomme, das vernünftig funktioniert
und das, was man früher so immer gemacht hat
wie JQuery und sowas, definiere ich
definitiv nicht als vernünftig funktionieren.
Ja, das hat nicht, also
man kommt damit erstaunlich, aber das hat nie wirklich
gut funktioniert, das ist richtig, ja.
Wobei ich
eine Sache hinzufügen würde, etwas, was
ich in letzter Zeit auch häufiger mache und wo ich auch
denke, oh, das ist auch alles gar nicht schlecht und es geht in die
richtige Richtung, sind halt so Web Components,
das ist eigentlich auch ganz nett,
da muss man dann halt JavaScript schreiben, das ist halt
so ein bisschen doof, aber
man kann halt irgendwie, das hält sich
dann halt in Grenzen. Also und
man weiß halt, also das habe ich
letztens wieder erlebt und das tut jedes Mal weh,
irgendwie größere
Projekte, die man lange nicht angefasst hat, irgendwie
das ist immer schmerzhaft.
Also wenn man jetzt irgendwie
ja da so, zum Beispiel das war
jetzt mein View-Projekt, es ist halt
irgendwas geht nicht mehr
und es dauert immer, bis man rausgefunden hat,
was denn da jetzt eigentlich das Problem ist und bis das
alles wieder rund läuft und dann
vergehen vielleicht auch nochmal ein paar Tage
oder Wochen, bis man wirklich alles gefunden hat, was
vielleicht nicht mehr ging, weil manchmal war es das nicht so offensichtlich
und das ist einfach total
nervtötend, also
genau, das Problem hat man mit Web
Components halt auch nicht, weil das ist halt Standard
und wenn das jetzt funktioniert,
funktioniert das in
zehn Jahren halt auch noch ganz genauso und
ja.
Tatsächlich haben wir zu dem Projekt mal
Django Components ausprobiert, das ist ja auch eine von diesen
vielen Ansätzen, da gibt es auch Django Slippers und wie die
alle heißen, um
Was war das letzte? Django Slit?
Slippers.
Um im Endeffekt dieses
Komponentendenken in die
Django-Welt zu bringen, weil de facto
die Django-Template-Welt ist ja immer noch, wie sie
vor 15 Jahren mal irgendwann angefangen hat
und da zu überlegen, dass man
Komponenten bauen möchte, vor allem in so einer Kombination mit
Tailwind, die ja dann eher diese
Utility-Base-Klasse, also ein normales
Tailwind-Diff hat noch
10, 15 Klassen.
Das eskaliert ziemlich hart.
Ich finde es gut, aber
wie gesagt, es ist nicht schön
anzugucken und von daher die Sachen eher zu kapseln
und zu sagen, ich habe jetzt nicht, wie bei Bootstrap
zum Beispiel früher, ich habe hier
eine Button-Class und dann sieht jeder Button halt so aus, wenn ich
was überschreiben muss, bin ich halt arm dran,
dann wird es schwierig,
sondern dass man wirklich die Sachen individuell
mit diesen Klassen halt definieren kann, ohne halt
die ganze CSS-Magie dahinter 100% verstehen
zu müssen. Und da
diese Komponenten in der Django-Welt
zu machen, klingt super interessant.
Das konnte man vorher auch schon mit Includes machen.
Ja genau, mit Includes. Es gibt auch eine neue Version
von Includes irgendwie, die das so ein bisschen
zwischenspeichern können irgendwie auch.
Ja, auf jeden Fall, da gibt es Packages,
die explizit dafür da sind, um diese
Frontend-Learnings auch in die Django-Welt
zu bringen. Wir haben uns jetzt für Django-Components entschieden.
Das scheint auch okay gut zu
funktionieren. Habe auch von einem Freund gehört,
der das ausprobiert hat, der da meinte, dass er damit
gut und der eigentlich auch sehr viel
und gerne im Frontend gemacht hat, jetzt aber aus
besagten Effizienzgründen halt gewechselt ist.
Und
genau, das
ist auf jeden Fall eine interessante Sache. Also wer sich
damit beschäftigt und halt ein Frontend
bauen möchte, für das man sich in 2024
nicht schämen muss, dann glaube ich, ist
diese HTMX, AlpineJS und dann irgendwas
an diesen Komponentenlibraries, die sich gerade, die
emergieren gerade alle. Also ich glaube, da gibt es noch nicht so
diesen de facto Standard.
Aber wenn man sich da so ein bisschen rein
liest, da findet man relativ, also
nicht viel, viel, aber da gibt es auf jeden
Fall schon Inhalte und
da kann man sich am Ende vielleicht auch irgendwas aussuchen.
Das ist alles nicht so kompliziert,
was einem gefällt.
Habt ihr mal schon mal herumgespielt mit dem
HTMX-Ding
für Mobile?
Das ist ja in dem Hypermedia-Systems-Buch
das letzte Kapitel,
wo es dann darum geht, dass man
das Ganze auch in Mobile einsetzen kann
oder soll oder so.
Als so
Ja, so eine Art von
XML-Endpunkt,
die dann irgendwie gerendert werden kann
von, ich glaube, React war es tatsächlich,
React Native. Ach so, ja.
Und dann Apps hat auf dem
Telefon, die dann diese einzelnen Komponenten
halt mitziehen können, einfach
von deinem normalen Endpunkt
klingen will. Ja, klingen will. Ich habe es noch nicht,
nee, habe ich nicht angeguckt.
Also ich habe auch für
so
Mobile, finde ich, eigentlich sind die Webviews
oder wie heißen die noch?
Progressive Web Apps, genau.
Ist eigentlich eine sehr, sehr schicke
Geschichte. Geht auf iOS auch deutlich
mehr inzwischen als früher. Wurden die nicht irgendwie
gebannt? Ne, also
das, ah ja, Apple hat da gedroht,
aber das ist dann nicht passiert.
Glücklicherweise. Ja, hat doch
ein bisschen zu viel Gegenwind gegeben.
Ja, und
ich denke, dass man vieles, was
halt man irgendwie
vielleicht mit nativen Apps früher gemacht hat,
auch mit, ja genau,
Progressive Web Apps hinbekommt
und
ansonsten sind halt die Mobile
Geschichten halt immer so eine komplizierte Geschichte, wenn man
da wirklich eigene, es ist halt,
Ich meine, für manche Sachen, wenn man
eh dafür ein Team hat und genug
Geld, dann kann man schon machen.
Ich würde das tatsächlich irgendwie mal ausprobieren.
Ich finde diesen Ansatz ganz cool.
Media für
für Mobile
auszuprobieren, das klingt irgendwie super.
Das ist derselbe Standard da und derselbe Prinzip.
Ist jetzt eigentlich, glaube ich, eine ganz
gute Überleitung zu dem nächsten Mini-Thema,
nämlich Lightning Talks.
Wer es nicht kennt,
die Lightning Talks, das ist bei den
Django-Cons zumindest, ich war noch auf keiner anderen Konferenz,
aber ich glaube, es gibt so Online-Konferenzen,
die jetzt am Ende des Tages
fünf bis zehn Leute einen
hart getimten fünf Minuten
Maximalfortrag halten können bei irgendeinem
Thema. Das heißt, die Vorbereitung ist
sehr gering bis nicht vorhanden
bei den Leuten. Aber das ist ja cool.
Der coolste Vortrag, den ich gehört habe, war
Fuck it. Zwei Minuten.
Und die Idee dahinter
ist einfach, genau das, was du gerade
gesagt hast. Ey, ich habe dann im Buch dieses Kapitel gelesen,
finde ich da halt spannend, habe ich noch nicht ausprobiert,
wollte ich euch mal mitgeben. Oder, was ich
vorhin gemacht habe, ey, es gibt Jungle Components, wer
sich dafür interessiert, schau ich das mal an.
Und da ist normalerweise die
Informationsdichte sehr hoch
und auch die Unterhaltungsdichte sehr hoch, weil natürlich
Leute auch dann einfach mal einen Spaßvortrag machen
oder irgendwas Absurdes aus ihrem
Alltag erzählen.
Ja, und dann kannst du deine Ukulele mitbringen.
Ja, genau. Und ich finde,
dass wir haben jetzt das auch bei uns
intern in unserem, also bei
meiner Firma
bei den internen
Barcamps so gemacht, dass wir auch einen expliziten
Lightning-Talk-Blog haben, weil viel
von so Content-Teilen
und Wissensmanagement scheitert daran, dass die Leute
sich wirklich aufraffen müssen, Sachen
vorzubereiten, Sachen zu recherchieren. Es gibt gewisse
Ansprüche, die Leute an sich haben. Es gibt vielleicht
Erwartungshaltungen, die existieren
mögen oder auch nicht existieren mögen. Aber so
Lightning-Talk gibt es das halt nicht. Du stellst dich
da hin oder in dem Fall jetzt in der
Post-Corona-Neuen-Moderne,
du sitzt dann vor deiner Webcam
und teilst dann halt kurz deinen Browser oder deine
zwei Slides und sagst, Leute, das habe ich
gesehen, das habe ich gelernt voll gut.
Oder auch Vollkacke. Und das ist ein echt cooles Format, den man auch, wie gesagt, gut, glaube ich, in Firmen oder auf Meetups auch sehr gut. Wir haben mal einmal vor ein paar Monaten, ich glaube im Februar diesen Jahres, haben wir eine komplette Lightning Talk Session gemacht beim Django Meetup Köln hier. Und das ist echt ein cooles Format, was viele von den Problemen löst, die man sonst so hat, wenn man Content teilen möchte.
Ja, ich finde auch, also gerade in jedem Format,
also das irgendwie für Konferenzen oder Barcamp
oder was man auch immer hat, wo man zusammen arbeitet,
ist dieses Lightning Camp, äh,
Lightning Talk Format
echt cool geeignet, um so ein bisschen
lockere Atmosphäre reinzubringen.
Entweder am Ende eines Tages oder am Anfang
von diesem, wir teilen uns irgendwelche Sessions auf,
so kurze Slots, selbst wenn es nur eine Viertelstunde ist,
zwei Minuten oder eine halbe oder sowas,
um so ein bisschen mit den Leuten so
reinzukommen, das ist echt schön. Ich glaube auch
außerhalb vom Coding, ehrlicherweise.
Man muss halt, glaube ich, immer noch so auffassen, dass man halt wirklich hart
guckt, dass die nicht überschritten werden,
weil einige Leute dann ihr Co-Referat halten,
dass dann doch ein bisschen länger wird.
Ja, das nervt die meisten
immer, glaube ich, aber ja.
Und eine andere super Sache ist halt auch einfach mal
ein Gefühl zu bekommen, ob man selber mal einen Vortrag halten möchte.
Eingangs habe ich ja gesagt, das war echt eine richtig coole Erfahrung
und ich habe
auf der letzten Konferenz in Edinburgh
habe ich auch einfach mal
einen Lightning Talk gehalten, um mal
zu sehen, um mal so den Fuß ins Wasser zu
halten, wie ist das überhaupt?
Über was?
Um den Fuß ins Wasser zu halten.
Über was soll der? Ach so.
Über Füße ins Wasser halt.
Nur über Füße und Wasser.
Angeln mit den Zehen.
Das war die Frage.
Ich habe tatsächlich
keine Ahnung. Ich habe dieses Jahr einen
über meinen Django Migration Zero
Package gehalten.
Ich beantworte meine Frage aber mit diesem Jahr,
weil ich es beim letzten Mal vergessen habe.
Ist ganz cool. Es ist ein Pattern, das hat sich
2018 jemand ausgedacht. Wer schon mal mit
Django Migrations gearbeitet hat und
länger auf einem Projektbeweis, da sammeln sich ziemlich
viele Migrations nach kürzester Zeit an.
Diese Migrations, wenn man die
volle Kontrolle über seine Datenbank hat,
also zum Beispiel beim Package hat man das nicht, weil das
installiert sich irgendjemand und dann macht irgendwer was damit.
Das ist außerhalb der
Macht des Creators. Aber in so einer klassischen
Applikation, die man baut, hat man eigentlich die volle
Kontrolle über die Datenbanken. Dann ist irgendwann
es auf dem letzten
Product-Release-System angekommen und die Migrationen haben de facto
eigentlich keinen Wert mehr, außer vielleicht einen historischen,
der aber auch sehr relativ zu sehen ist,
weil abgesehen von natürlich Custom-Datenmigration
die ganzen Sachen auch im Git irgendwie, die ganzen
Modeländerungen hinterlegt sind.
Viele Migrationen führen dazu,
dass die Tests langsamer laufen, dass die
Testdatenbank aufgebaut wird, weil
oft ist es ja so, dass es ja nicht ist, man
fügt immer was hinzu, sondern da kommt was hinzu,
dann kommt wieder was weg, dann habe ich was geändert, dann habe ich zum
18. Mal irgendwas geändert und
Django bietet dafür eine Möglichkeit an, das nennt sich
Squash Migrations, um das aufzuräumen.
Das Problem ist, das kann sehr, sehr schlecht mit
Circular Imports umgehen.
Also sprich, ich habe einen User
und der hat ein Projekt und das Projekt
hat, keine Ahnung,
Kommentare und die Kommentare haben wieder den User.
Das heißt, man muss dann, wenn man das macht,
diese Migration
sehr stark auseinanderziehen. Also wie man das
auch bei Circular Imports machen würde, das ist ja ein generelles
Python-Thema.
Und das ist sehr, sehr mühsam, was dazu führt.
Lazy importieren und die Sachen da als Strings hinschreiben.
Genau. Und wie das halt dann immer so ist
mit Sachen, die mühsam sind, die Leute machen
sie nicht. Umso einfacher Sachen sind, umso schneller
und umso besser werden sie getan.
Und es gibt einen Pattern, das nennt sich Migration Zero
Und das hat sich jemand bei Medium 2018 ausgedacht, da sitzt er schon eine Weile und die Idee ist halt einfach auf Deutsch gesagt, du löscht halt einfach alles, haust alles weg, was du hast und lässt einfach Django initial neue Migrationen erstellen.
Das klappt auch für große Projekte sehr gut, also ich hatte das beim richtig großen Projekt, mit großem Entwicklungsteam, fünf, sechs Jahren Laufzeit, hatte ich einen Mini-Konflikt, der aber auch so offensichtlich war, dass ich ihn sofort lösen konnte.
Also es war wirklich gar kein Problem. Und da habe ich halt dann dieses Package gebaut, das dieses Pattern implementiert und das ist im Endeffekt ein zweistufiges Ding. Einmal habe ich einen Helfer gebaut, der halt einem Verein quasi durch alle Apps geht, die Sachen aufräumt, weil das tatsächlich auch, wenn man das öfter macht, ist es, je nachdem wie viele Apps man hat, ist es auch Arbeit, auch wenn es doof klingt.
Und das zweite ist ein Skript, das in die Pipeline geht, weil Django hat ja alle Migrationen, werden in der Datenbank in so einem Log, in so einer Historientabelle hinterlegt, da quasi noch die Änderungen anpasst. Das heißt, du kannst einfach in die Pipeline hängen, du hast den Django-Admin in Switch, du kannst sagen, ja, jetzt habe ich Migration gelöscht, jetzt bitte beim nächsten Deployment, bereite bitte die Datenbank auf, um diesen Prozess zu streamlinen.
Und das ist ein Thema, das verkauft sich sehr schwer, weil es ist halt, wie wahrscheinlich es auch der geneigte Zuhörer gemerkt hat, relativ tief und auch nur so ein Edge-Case und eigentlich sollte man es tun, aber so richtig Lust hat da keiner drauf.
Ich weiß, da hat es schon mal drüber gefallen, dass sie irgendwie dann Migrations erinnert haben, dann bumm, oh, Daten-Migrate nicht.
Genau und ja, aus dem Grund fand ich das eigentlich für ein Lightning-Talk ein ganz cooles Thema, weil so war das den Leuten so, Leute, wenn ihr das Problem habt, guckt euch das an, das gibt's.
Ich habe dabei, als ich das Package gemacht habe, auch direkt noch eine zweite Sache gelernt. Es ist super, wenn man einen coolen Namen für sein Package hat. Man sollte aber vorher gucken, ob der vielleicht schon belegt ist, weil es gibt nämlich ein Django Zero Migration und Migration Zero ohne Django, glaube ich, bin ich ganz sicher.
Du hast es dann Zero Migration 2 genannt.
Django Migration Zero gab es tatsächlich
noch nicht. Aber es ist
natürlich trotzdem allein schon wegen SEO extrem
blöd, wenn halt dann Leute ständig aus falschem
Package kommen, weil das andere halt schon seit 2014
da rumsitzt mit einem Commit.
Genau, von daher, wenn jemand ein Package
erstellt, dann checkt vorher die Namen ab, das hilft.
Genau.
Jochen sollte das Package unbedingt mal benutzen.
Ich habe ja gestern nochmal über die Schultern geguckt, als du DjangoCast
migriert hast und irgendwie wie viele Migrations
da allein von weg herangekommen sind. Das waren ja hunderte.
Ich habe mir das auch überlegt, dass ich das überall
wegschmeißen möchte. Aber dann denke ich mir immer,
das sollte ich vielleicht dann machen, wenn sich an der Datenbank
nicht mehr so viel ändert.
Aber ich werde das auf jeden Fall
tun. Ich würde mich freuen, wenn du mein Package
ausprobieren würdest. Ja, kann ich mal
probieren, genau. Aber das Problem
ist auch bei mir, es ist halt
blöderweise eine Library und ich werde
Leuten... Bei der Library geht es eh nicht.
Da musst du ja mit
Squashen arbeiten.
Du weißt ja nicht, in welchem Stand
quasi, dass die letzte Person
dein Package
oder die Person dein Package nutzen?
Ja, vielleicht werde ich
bei irgendeiner Major-Version...
Release-Update und wer weiß,
wie viele Leute aus der Jochen sein Jochen-Paket
haben. Ja, kann sein, dass es nicht so viele sind.
Das ist schon richtig, genau.
Schieße ich nur in meinen Fuß
und nicht in den Fuß von noch 100 anderen Leuten.
Das kann ich vertreten.
Das Risiko von Open-Source-Hafen, ja genau.
Und man kann ja dann downgraden.
Datenbank brennt, sorry, Downgrader einfach.
Ja, ja, ja,
aber ja, das ist ein Problem.
Ich meine, das ist auch so ein Problem wie bei so Projekten
wie zum Beispiel Wagtail.
Da hat sich halt, es ist ja auch schon recht alt
und das ist halt auch, das verwendet man ja auch
als Library und da hat sich so viel Zeug
angesammelt, dass halt das mit dem Testen,
also wenn man jetzt quasi
und mein Paket hängt zum Beispiel auch von Wagtail ab,
deshalb muss ich für alle Tests
und so immer so Wege drumherum finden,
dass ich auf jeden Fall beim Testen nicht die
Migration laufen lassen
muss, weil sonst werden die Tests
irre langsam. Ah, dann machst du ReuseDB.
Ja. Und dann musst du halt dafür ganz hart sorgen,
dass alle Funktionen so wieder aufgeräumt werden.
Minus Minus ReuseDB, Minus Minus No Migrations, genau.
Aber dann gibt es halt dann so Fälle, wo
ah, nee, dann muss man es doch haben. Wie man zum Beispiel
wenn man dann halt vertroxt die ganzen
unterschiedlichen Versionen durchgeht,
dann muss man natürlich wenden, wenn man jetzt, dann kann man
nicht die gleiche Datenbank verwenden. Dann muss man halt schon
die Datenbank wieder wegschmeißen, wieder neu.
Es geht, aber es ist halt
es ist hacklich, ja.
Ja, ja. Ja, einzelne Pipeline.
Ja, du hattest ja gerade mich schon wegen Edinburgh gefragt, was ich sehr interessant fand jetzt in Vigo. In Edinburgh gab es von mehreren Leuten die, ich glaube auch berechtigte Kritik, dass die Themenauswahl zwischen, meistens kann man das ja grob in Community Talks oder Community Talks und Tech Talks mit vielleicht Meta Talks, die so irgendwie dazwischen sitzen, aufteilen und in Edinburgh war es relativ stark auf der Community Seite.
Also Leute, die über Community-Erfahrungen berichtet haben, wo Parallelen gezogen werden zwischen anderen Arten von Communities. Meine Erfahrung, wie ich das erste Mal zu Django Contributed habe, solche Geschichten. Das gab in Edinburgh von mehreren Leuten die Kritik, dass das halt relativ viel war und das ist mir positiv aufgefallen, dass ich fand, dass die Mischung aus den Community-Talks und aus den Tech-Talks und aus den Meta-Talks richtig gut war.
Und ich sehr, sehr happy war mit der Thema-Auswahl.
Ich meine, wie gesagt, es sind halt immer eine große Menge auch von Leuten,
die das mit Absicht zum ersten Mal machen,
die Englisch nicht als Muttersprache haben und sowas.
Das ist natürlich immer Sachen...
Ich habe immer gehört, dass Spanien immer so ein bisschen anstrengender ist,
was so das angeht.
Also für Englisch, weil halt da Englisch nicht so verbreitet ist
und viele Leute halt dann nicht so...
Ja, also wir hatten auch, glaube ich, gar nicht so viele Spanier.
Ich glaube, eine Frau aus Katalonien,
was so ein bisschen Definitionssache
aus Spanien ist oder nicht.
Und ansonsten,
ja, vielleicht ein, zwei, aber
wie gesagt, generell fand ich das
diesmal gut. Es war
sehr angenehm, waren viele interessante Sachen dabei.
Da gab es zum Beispiel einen
von Octopus Energy, das ist einer von den großen
Django-Playern, die auch eigentlich immer so mit Platinum-Sponsor
bei den Konferenzen sind, über
Layered Architecture bei Django. Ich bin schon sehr gespannt, wenn das
Video rauskommt. Das war sehr, also
bei YouTube werden die ja alle veröffentlicht.
Das war sehr, sehr viel
Informationen da drin und ich habe
mir nur ein ganz, ganz paar wenige Fotos gemacht
und ich bin sehr gespannt, mir das Ganze noch mal in Ruhe
zu Hause anzuhören.
Genau, wie geht die Background Workers,
die Sache von Carlton Gibson, es gab coole Meta-Talks.
Also
das fand ich von der Auswahl
her, bin ich da mit vielen schlauen Gedanken
nach Hause gegangen.
Und was ich auch
sehr interessant fand bezüglich des Community-Talks,
direkt die allererste Keynote
ging um Django Girls. Das ist
eine Vereinigung,
ein Non-Profit, glaube ich, inzwischen auch,
die dafür da ist,
explizit Frauen ans Programmieren
ranzuführen, weil es ja immer noch so ist,
dass halt die IT-Branche immer noch hart in Männerhand
ist und das soll einfach
vor allem die Mädels
so ein bisschen ermutigen, dass sie das können.
Also nicht irgendwie, ich glaube, da ist
gar nicht so groß der Faktor, dass du da rausgehst.
Also das ist immer so ein Wochenende-Workshop.
Positiv bestärken viele und so, genau.
Und der YouTube-Python ist auch, glaube ich, ein ganzer Workshop
für Tango Girls.
Und ich war, als das mal hier in Köln war, 2015 glaube ich, war ich auch mal da Coach und das war eine sehr interessante Erfahrung, hat echt Spaß gemacht und war auch interessant, weil die Mädels, da habe ich alle komplett noch nie irgendwas programmiert haben, also wirklich, die waren komplett bei Null, die drei, die in meiner Gruppe waren und wie die da auch unterschiedlich rangegangen sind, das war wirklich auch für mich, also im Sinne von, man hat ja auch immer wieder mal mit neuen Leuten zu tun, wenn mal jemand Neues anfängt, wenn man mal Werkstudenten betreut oder sowas, echt interessant zu sehen.
dieses Coaching
zu machen. Und wie gesagt, das ist halt
vor zehn Jahren, das war jetzt Jubiläum, in Berlin
gegründet worden, was ich auch ganz cool finde.
Also sprich, wenn
jemand jemand kennt, der
also jemand eine Frau
kennt, der die potenziellen
sowas Interesse hat, die werden immer wieder mal
hier und da angeboten, diese Workshops.
Und das ist glaube ich
echt cool, so für
den ersten Fuß ins Wasser
halten mal wieder. Und
die Idee dabei ist, dass die halt im Endeffekt
ihre erste Django-Seite erstellen
und auch irgendwo hindeployen. Und
der Fokus ist halt eher darauf, wie du schon gesagt hast,
positive Bestärkung, denn
ja, pädagogisch
wertvoll. Das Tutorial ist auch relativ
gut und relativ komplett.
Wenn man überhaupt mit Django ansteigen will.
Ich meine, das hätten wir jetzt vielleicht früher sagen müssen,
die Leute, die jetzt noch drin sind, sind wahrscheinlich
eher schon tiefer auch in Django, aber ja.
Vielleicht können wir das da weiter verraten auch.
Ja, aber das sind dann auch die Motivierten.
Bei denen lohnt sich das dann.
Ja, vielleicht tragen das in ihre eigenen
Communities weiter auf. Genau. Du kannst einfach
in der Linksammlung noch hinzufügen, da freuen die sich.
Ja, ja, mach ich auf jeden Fall.
Ich hab das auch tatsächlich an die Neulinge
bei uns mit Django, auch einmal Django Girls.
Also erst natürlich offizielles
Tutorial ist nicht schlecht, aber Django Girls auch so schönes
schnelles Einstiegsding.
Ich erinnere mich gerade, ich war jetzt zu langsam, um da
einzu... Ich hab mich dann irgendwann
kurz danach daran erinnert, es gab auch
jetzt irgendein...
Muss ich auch nachgucken, welcher das war.
Podcast-Episode Django Chat mit
einer von Octopus Energy
und die erzählte
da auch irgendwie, ja,
dass sie halt
auf so ein Problem
gestoßen hat, dass sie eigentlich nicht
wollen, dass in Templates irgendwie Datenbank
Queries passieren oder so. Und das
ist auch etwas, was mir inzwischen halt,
ich habe ja versucht, so ein bisschen Performance-Optimierung
zu machen, auch bei den
beim DjangoCast-Ding, was ich
baue, und das ist
mir auch ganz böse auf die Füße. Also
Also eigentlich, da dachte ich auch so, oh ja, eigentlich möchte man nicht, also wenn man in Templates Datenbank-Queries macht, ganz blöde Idee, die sind dann so weit gegangen zu sagen, sie benutzen so eine Art Class-Based Views, wo sie halt verhindern, also sie nehmen nicht die Modelle, sondern sie machen irgendwie da so Data-Class-mäßig irgendwie Read-Only-Kopien von den Dingern, sodass wenn du da irgendwo was versuchst aus der Datenbank zu holen, dass das halt einfach nicht geht.
Und das kann ich gut verstehen, das ist eine, also du willst eigentlich, wenn du zum Beispiel eine Daten, die Anzahl der Datenbank-Querys und so toll überhalten willst, willst du halt irgendeinen Punkt haben, wo du sagst, also hier, da sind alle Queries und ich mache nirgendwo anders welche, weil das ist so schwer zu containen, wenn man, wenn da irgendwas passieren kann, dass es halt ganz blöde Performance-Implikationen hat.
Und wo man dann quasi durch das Frontend auch Angriffe machen kann oder was?
auf... Nee, Angriffe, also es ist einfach
irgendwie, das ist halt
unheimlich,
macht Dinge halt deutlich langsamer und man
weiß gar nicht so, warum irgendwie.
Und, ja.
Also zum Beispiel... Warum wird das
langsamer? Vielleicht müssen wir das nochmal genauer erklären.
Datenbank-Queries sind immer super langsam. Ja, aber warum
muss das, also wenn man die eh machen muss,
warum dann nicht im Template, also man muss ja eh
drauf warten. Naja, wenn man die halt
an einer Stelle macht, dann ist es halt auch nicht so schlimm.
Also was auch, das weiß ich nicht so genau.
Das ist ein Gefühl. Das habe ich noch nicht wirklich gemessen,
aber ich habe auch das Gefühl, dass
wenn man die Datenbank-Credits sehr
verstreut macht, dass das halt
besonders schlecht ist auch. Warum das genau ist,
weiß ich nicht.
Also an verschiedenen Stellen im Code,
meinst du 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. Auch erstaunlich
viele, das weiß ich jetzt, weil ich es halt so ein bisschen
geproffelt habe. Bei mir sind es
halt von, also wenn man jetzt
einen Blog nimmt und da die Listpage und dann
halt nur so fünf Artikel oder sonst irgendwas, also
aus diesem Listview, dann macht das
halt so 110.000
Funktionsaufrufe oder sowas, was
eine Menge ist. Ich dachte so, wow, shit, warum ist
das so viel? Das ist ganz schön viel.
Und mein Ding wäre jetzt, wenn jetzt so
alle tausend
Funktionsaufrufe kommt, irgendwie Datenbankquery.
Das ist schlecht. Also so war
es quasi vorher irgendwie implizit,
weil 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 jetzt diese Datenbank-Queries, an denen ich
selber noch gar nicht viel geändert habe, alle an einer Stelle passieren,
ist es irgendwie doppelt so schnell geworden.
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 Jungle-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 warst du irgendwie vorbereitet
oder tiered down oder so hin und her,
kostet dann unheimlich viel, oder? Ja, also
ja, das allein,
dass man da halt irgendwie viele Objekte erzeugt
und dann, ja,
und wenn das halt an einer Stelle ist, dann passiert das halt
einmal und wenn das halt verteilt ist, dann
macht es das irgendwie nochmal langsamer
und ja, ich versuche immer noch momentan gerade
rauszukriegen, woran liegt das eigentlich, dass da so viele
Funktionsaufrufe passieren, weil das ist einfach zu viel.
Kann man nicht eventuell,
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, Tim, wie groß
hältst du, wenn das in den RAM passt? Ja,
das ist alles gar kein Problem.
Aber kann ich so eine
Query formulieren und wenn ich jetzt die Daten
aus dieser Query habe, kann ich die so transformieren, dass ich
daraus wieder Django-Objekte machen kann.
Das ist halt so. 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
zum Beispiel als Sticked haben.
Dass man halt auch irgendwie serialisieren kann.
Wenn du Django-Objekte hast, die kannst du nicht,
also es gibt viele Dinge an Django,
die kannst du nicht serialisieren.
Du kannst es auch nicht cachen, weil
Curry-Sets kannst du nicht gut cachen. Geht nicht.
Aber wenn du jetzt das in eine
Dict-Geschichte
überführt hast, wie im Prinzip
JSON sehr realisierbar ist, dann
kannst du halt auch das, was du aus der Datenbank kriegst,
einfach nehmen, irgendwie auf eine Platte schreiben oder so
und sage, okay, die nächsten fünf Minuten einfach
das Pfeil nehmen und nicht mehr die Datenbank fragen.
Oder irgendwo in den Hauptspeicher oder in Redis oder sonst
irgendwo hin. Und dann kannst du
das halt cachen. Aber das, genau.
Und aus
den Dingern 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.
Ja. Und ja,
genau. Also ja, ich mache momentan so ein bisschen
Performance-Optimierungsgeschichten.
Ja. Ja. Tja, ja.
Ja. Ja, aber wenn Performance
auch dazu führt, dass du weniger Rechenleistung aufwenden musst,
ist das ja sogar Green Engineering.
Ja, ja. Da gab es auch Vorträge
dazu. 110.000 Funktionsaufrufe
für ein Webseiten-Rendering ist nicht so richtig
green. Ehrlich gesagt, das ist eher so mehr so braun.
ja. Aber Walter, ich habe gerade
deinen Einstiegspunkt
vergessen, der mich daran erinnert hat, aber es war
super interessant, bei diesem Jungle Girls Vortrag
gab es auch so eine,
ja, so Success Stories einfach,
von Mädels, die das halt teilgenommen
haben und die jetzt halt irgendwo einen coolen Job
haben oder irgendwie eine coole Erfahrung haben oder irgendwo
sich halt irgendwas Positives in ihrem Leben geändert hat,
so im Sinne von, das hat einen Impact
und was ich da echt
krass fand war, dass eine US-Amerikanerin,
die daran teilgenommen hat, die halt vorher irgendwas
gearbeitet hat und jetzt halt dann in Tech eingestiegen
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
es nicht bewerten, ob das stimmt, also ob das
jetzt so 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, dass halt, wenn man, also so
Programmierer ist jetzt schon, ist jetzt auch nicht
das Bestbezahlte überhaupt, aber
sagen wir mal so, ist 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, dass es immer noch weiter gut bezahlt wird.
Auch wenn wir Probleme haben, unsere Kinder zu ernähren.
Ja.
Ich glaube auch, es ist ja
nicht nur das Geld, sondern auch, dass man so eine gewisse
Flexibilität hat. Ich meine, es gibt
immer noch diese Marketingagenturen,
wo man dann irgendwie bis nachts um
zwölf irgendwie irgendwelche
Marketing-One-Pager zusammen lö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 Familie und Beruf.
Genau, ich ziehe mit reicher Arbeit von zu Hause aus eine Menge Geld verdienen. Hier ist idealer Angewohn.
Nein, aber ich glaube, gesellschaftliche Transformation wäre sowas wie Vereinbarkeit eine der Hauptdinge, glaube ich.
Also fällt mir auch immer wieder auf, ja, das ist halt total hart,
wenn irgendjemand den ganzen Tag irgendwo hinfahren
muss, und dann mit Kinderbetreuung ist es schon schwer, ne?
Ja, also ich meine
auch jetzt die Erfahrung, in den letzten Jahren
Erfahrung mit Kinderbetreuung, es passiert immer so
viel 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
Ja, oder hinfahren jeden Tag, du fährst abends mal
abends abends abends nach Hause. Du kannst auch nicht wirklich wegfahren,
das wäre echt übel gewesen, ja. Oder Schichtdienst,
einfach die ganze Nacht. Ja, ganz übel, also
Ja gut, aber es gibt Leute, die kriegen das trotzdem irgendwie hin,
Ja, es ist sehr beeindruckend.
Ja, du wolltest jetzt
über Party reden, auch wenn wir gerade für Kinderkriegen reden.
Ja, für manche Leute ein Thema.
Nach der Party kommt der Kater.
Genau, nein, tatsächlich
bei den Dungercons gibt es immer eine Party
und ich finde 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
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 irgendjemand
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. Weil nicht eingeladen zur Party.
Ach so.
Und einfach, weil halt das Heck hier nicht gesetzt wurde
und das war halt irgendwie einfach
so ein bisschen die Realität zu
Theorie. In der Theorie ist es kein Problem, in der Praxis
naja, so ist es halt. 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
eher am Ende.
Das ist mir in den Videopeisen auch aufgefallen, da gibt es auch mehrere Partys, wo man sich extra
registrieren muss.
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 noch mal
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, die war echt gut organisiert,
richtig schöne Location, bestes Wetter,
alles draußen.
Und da bin ich dann einfach in eine Runde
von Leuten reingestolpert und dann bin ich
halt nachher mit einem im Gespräch hängen geblieben und nachher
irgendwann meinte er, weißt du echt, wer ich bin?
Ich sage, keine Ahnung, ich bin Präsident
hier von Django Software, von der ich sage, oh,
ups, sorry,
da kannte ich halt noch nicht so viele Leute in dem Umfeld
und es 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,
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 irgendwie die eigene Crew irgendwas
und 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 es ja immer dann auch, ne, auch dann so, naja, nö, sie nehmen es auf, nö, aber ich finde es ist schon sehr, sehr schöne Atmosphäre und Möglichkeit mit Leuten nochmal so zu socialisen, 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 Meerblick. Und die andere Seite der Bucht war schön. Hatte eine gigantische Dachterrasse, also riesig. Und genau oder fast genau als die Party anfing, kam ja 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 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 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 ein sehr schöner 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 auch immer der Hauptteil des Spaßes ist, also nichts gegen die ganz tollen Vorträge, die alle tollen Menschen machen, mir halt auch bestimmt bei der DangoCon, wo ich irgendwann 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 was Gutes.
Ich kann das auch sehr nachvollziehen.
Ich finde das auch mit den wichtigeren Teilen.
Also manchmal ist man halt auch im Gang so ein bisschen.
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 von der Europython 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 sich 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 näher nochmal an irgendeinem Stand.
Und man hält sich dann mit den Leuten länger, anstatt dass man jetzt sagt, okay, meine Uhr in zehn Minuten geht der nächste Vortrag los, 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 das 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 bei den Workshops da und haben nie wieder gesehen. Oder Leute, die schaffen sogar nur zu ein oder zwei Vorträgen, was manche an Kinderbetreuung liegt oder sowas, die man da auch netterweise hinbringen kann. Oder halt sogar nur zu den Sprints, 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-Connect auf jeden Fall auch mal reinziehen, 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.
Ich auch, ich fahre trotzdem gerne nochmal hin.
Dublin ist toll. Weißt du auch schon wo?
Gibt es da einen Ort?
Es gibt glaube ich
eine Webseite,
wo literally das Logo drauf ist.
Alles weitere
folgt dann.
Ich finde es auf jeden Fall sehr cool.
Edinburgh und Vigo hätte ich wahrscheinlich beide auch gemacht.
Vigo kann ich noch nicht, Edinburgh schon.
Dublin, ja, ist das einfach eine tolle Stadt.
Wenn ich noch Bier trinken dürfte,
wäre ganz toll.
Überall wunderschöne Sachen.
Du musst halt Whisky trinken.
Ja, wir waren ja immer, ja, am Schennen entlang ist ja immer toll, da gibt es tolle Sachen, ich meine, es ist halt sehr moderne Hilfestadt auch, ne, naja, gut, das sind die meistens alle irgendwo, bis auf hier noch ein, ja.
Aber wie, das waren jetzt aber drei Tage quasi, ne?
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 war letztes Mal in Edinburgh 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 sehe ich total
anders, also weil, vielleicht bist du schon
viel weiter als ich in vielen Punkten, aber
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, ich gehe halt auch ganz gerne
auf die Konferenzen, nehme mir
die Stichpunkte mit und
sortiere dann quasi danach nochmal so ein bisschen
aus, so was speichere ich ab, also 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 gucke 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, so gehe ich dann damit um.
Ich weiß jetzt nicht, vielleicht gleich deine Länge der Workshop, also die Workshop, die ich hatte,
waren halt mindestens einmal einen halben Tag, also vier Stunden
oder so. Die sind kürzer da.
Ich bin da richtig tief in die Themen reingekommen,
hab mich da richtig reingehackt, hab da 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.
Ich bin nicht ganz sicher.
Letztes oder letztes Mal hab ich mal welche mitgemacht.
Aber wie gesagt, irgendwie die Atmosphäre ist nicht so ganz meins.
Ich konnte zum Beispiel auch konzentriert arbeiten, weil es da ruhig war.
Wo ich dir recht geben muss, ist bei den Sprints.
Sprints sind immer sehr chaotisch.
Meistens, also ich nutze Sprints oft dann auch zum Socializen,
mit den Leuten quatschen, um nochmal rumzustehen.
Aber ich muss ehrlich
gestehen, ich habe bei den Sprints auch immer nicht das Thema
gefunden, wo ich dachte so, wow, das finde ich jetzt super
toll und da will ich jetzt mitmachen.
Weil ich glaube, das ist, 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 das
Feature zu nehmen, 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 dann auch einen Open Source Sprint gemacht.
Der schon am Mittag war, wo ich leider erst so spät konnte.
Und das war
auch echt cool. Also es war eine coole Erfahrung.
Jeder hat da so ein bisschen an dem gearbeitet, wo er
drauf Lust hatte. Es sind mehrere Tickets
auch erstellt worden.
Und
also wurden mehrere Pulls erstellt
worden. Und danach
hat man noch so ein bisschen Diskussionen, so Future of Django.
War auch super interessant, weil man halt wirklich
mal zwei Boardminers am Start hat und
wirklich mit denen so ins 1 zu 1 gehen kann.
Aber wirklich, ich bin da gar nicht dagegen oder so.
Ich sage nur, das ist halt nicht so mein Arbeitsumfeld.
Ich finde, für das wirklich Programmieren ...
Also kategorisch, ja.
Also es ist nicht nur so zufällig gewesen,
sondern du denkst wirklich, du brauchst eher deine Ruhe.
Ja, definitiv.
Aber 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 die schöne Arbeitsatmosphäre hast
und das 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, als ich 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 wenn 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 das, wenn man eh mal gerade eine Pause
braucht, wenn man kurz vor die Tür geht oder so, dass man halt
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 im Büro sind, dass wirklich da ein gewisser
Lärmpegel entstehen könnte. Ich meine, natürlich
Ich telefoniere vielleicht mal irgendwer, irgendwo oder so.
Aber es gibt ja immer noch Kopfhörer.
Dann bin ich ins Boot, dann muss ich eine Hose anziehen.
Das ist so fürchterlich.
For the record, du hast jetzt auch eine Hose an.
Hey, jetzt hast du wieder gespoilert.
Nein.
Ich wollte jetzt niemanden zu nahe drehen.
Ja.
Ja, wir könnten noch Pics machen.
Das klingt, glaube ich, ganz gut.
Und dann ist es eigentlich auch schon
eine runde Sache.
Ja, dann bin ich
ja mal gespannt, was für Picks
wollt ihr denn nehmen?
Soll ich anfangen?
Du hast einen von mir geklaut.
Ich weiß gar nicht, ob ich den schon gesagt habe.
Hab ich den geklaut? Ja, das kann sein.
Ich hab mich in
letzter Zeit noch mal so ein bisschen
also es gibt da auch einen sehr schönen, das kann ich vielleicht
dazu sagen, Vortrag von
Simon Willison zu einem Kommando-Zahlen-Tool,
was er geschrieben hat namens
LLM 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
ja
unterschiedliche Modelle mal so ausprobieren kann,
damit man so ein bisschen rumspielen kann.
Aber auch, du kannst halt einfach
in deine Kommandos halt reinpipen. Genau,
du kannst halt, ja,
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 mach ich da irgendwie
ein System-Prompt zu, von wegen, ja,
hab 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.
Und dann kann man totalerseits 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.
Dann hat man halt immer schon sein
System prompt 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,
dann gibt der mir immer schnüppelische Antworten,
wie ich das von Jochen immer kenne.
Es funktioniert super, es macht sehr viel Spaß.
Und dann sagt der mir so,
warum hast du das denn nicht selber rausgefunden?
Jetzt auch die Anleitung.
Es ist toll und es macht so ein bisschen Spaß beim Arbeiten,
wenn man dann Fragen stellt und jemand, der dann so antwortet.
Das ist sehr lustig.
Sehr gut.
Genau.
Ja, also das Ding, ups.
Das wäre dann mein Pick, genau.
Ja, 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 einer Art und Weise erwähnt habe.
Oder hast du vielleicht mal einen interessanten Talk gesehen?
Oder du kannst ja, genau, wenn du einen Talk
zum Beispiel bei der DjangoCon 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 Architect
über 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
interessiert und auch in das,
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 Blog-Ding,
womit es mal angefangen hat, da gibt es
einen Talk, Scaling Django to 500
Apps, das ist auch
Kraken-basiert, 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,
ja, in general, 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 Sprint-to-Naming-Konvention,
um im Endeffekt zu sagen,
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 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 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, also es war super schnell, wie so Sachen reingehen, 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 Subwebs, das ist einfach Standalone.
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.
Subwebs habe ich auch letzte Woche in irgendeinem Projekt eingebaut,
aber ohne das Pattern dazu.
Aber ich bin eigentlich eher,
vielleicht bin ich da auch irgendwie falsch abgebogen,
aber ich bin eigentlich eher so auf dem,
ich mache gar keine Django-Webs mehr.
Also immer wenn ich...
Wie sonst?
Naja, einfach ganz stinknormal
mit Python-Bordmitteln
Dinge modularisieren.
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 du 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, man kann halt Sachen schlecht
refactoren, so von einer App zum Beispiel in eine andere,
weil man kann die Migration nicht umziehen.
Aber so Modelle, genau, wäre so ein Punkt, wo ich sagen würde,
oder 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 musst du halt
mit RAW-SQL und
Daten halt...
Ja, klar, das geht schon, aber es ist halt nicht einfach,
man verschiebt es...
Da kann man auch gut was kaputt machen.
Ja, genau.
Wenn man es halt alles in einer App hat,
dann kann man es einfach umziehen.
Das ist eine interessante Idee, da habe ich nicht drüber nachgedacht.
Ich habe meistens dann zum Beispiel Models.
Also wenn es größer wird, dann habe ich halt ein Models-Verzeichnis.
Alle 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 sollte man 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 die sind ja rein intern.
Das ist interessant, da habe ich noch nie drüber nachgedacht
Ja, das finde ich auch
Also unterverzeichnet ist, wo halt nur bestimmte Sachen
rauskommen und die anderen Sachen, also implizit
intern, aber
Das ist interessant, da habe ich heute noch drüber nachgedacht
aber auf diesen
das ist ein Benefit, da bin ich
drauf gekommen, das ist interessant
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
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 Command-Teile MonkeyType und
dann nimmt der halt die File oder das Ding
und schreibt da die Annotations dran.
Und das ist gar nicht so schlecht.
Das funktioniert besser, als man vielleicht denkt.
Und
wenn man halt gerade nicht so weiß,
man möchte irgendwas Type Annotieren, also warum
wenn man 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
man entdeckt manchmal sogar auch Bugs, weil man halt so, hä, nee, das stimmt
aber eigentlich gar nicht oder so.
Wenn man andere Sachen erwartet oder
oh, Mist, dann kommt auf einmal der Delinther
oder Maipai sagt halt so, nee, Moment, der stimmt
aber jetzt gar nicht, das ist schon ganz gut.
Interessant.
Ja, gut, dann würde ich sagen,
haben wir für heute die Episode.
Dann herzlichen Dank, dass du wieder da warst.
Ja, vielen Dank.
Dann machen wir es gleich noch unter uns weiter,
würde ich sagen. Herzlichen Dank fürs
Zuhören. Bleibt uns gebogen, wo immer ihr auch seid.
Danke, Jochen.
Und ja, Feedback
an hallo.at, peißenpodcast.de, Feedback,
Anregungen, Kommentare, Lob, Kritik und so weiter.
Was ihr alles möchtet. Bis bald.
Bis dann. Bis bald.
Tschüss.