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