Hallo liebe Hörerinnen und Hörer, willkommen beim Python Podcast, Episode 57.
Heute reden wir über die DjangoCon.
Hallo Jochen.
Hallo Dominik.
Und hallo.
Und hallo Ronny.
Ronny, hi.
Schön, dass du wieder da bist.
Ja, wunderbar.
Ich auch.
Dann fangen wir vielleicht mit ein bisschen News an und dann schlagen wir direkt ein, was
da noch los ist.
Jo, ich mache hier mal eine Kapitelmarke für News.
Okay, Kapitelmarke hat nicht funktioniert.
Ah, toll.
Nichts funktioniert hier?
Das ist ja nichts Neues.
Ja.
Das sind keine News
Wann war die nicht dann gekommen?
Erst mal damit an
Die war Anfang Juni in Vigo in Spanien
Nordspanien, Galicien
Eine sehr schöne Stadt
Ohne jetzt tatsächlich große Highlights, aber mir hat es trotzdem gut gefallen
Es ist ein sehr schöner Nationalpark
Ein Inselnationalpark direkt vor der Küste
Wäre mal die Gelegenheit, da hinzufahren
Das sollte man nicht verpassen
Ist das so quasi da irgendwo diese
Santiago de Compostela
Ja genau, das ist so ein bisschen südwestlich davon
Also genau nördlich von Portugal
und genau, ich hatte
einen Tag Zeit, wandern zu gehen,
auf der Isla Cies,
glaube ich, und
das ist wirklich sehr zu empfehlen.
Ging sehr gut.
Ja.
Ja, nächste Woche ist EuroPython,
vielleicht das News. Ich weiß nicht, ob man das noch hört,
wenn ihr darüber hört, vielleicht ist es dann schon vorbei.
Ja, wahrscheinlich.
Ja.
Wir möchten gerne ein paar Themen von der
DynamoCon hören und es gibt aber noch ein, zwei
andere News. Ja, genau.
Wir haben ja jetzt schon einige Zeit
keine Sendung mehr.
Das ist immer dasselbe Problem im Moment, aber gut.
Also ein News
ist ganz interessant.
Google ist ja so ein bisschen unter Druck in letzter Zeit.
Man sieht sie halt öffentlich schwitzen.
Dieses ganze
AI-Thema, das ist irgendwie, ja.
Können sie nicht so richtig
entscheiden, schlagen sie jetzt voll ein oder doch nicht?
Was machen sie? Oh nein.
Jetzt haben sie sich für etwas anderes entschieden,
nämlich ihr Python-Team zu feuern.
Die haben da glaube ich direkt wieder ein neues eingestellt, ich glaube in Deutschland sogar.
Ja, sie sind jetzt, also es ist zu teuer mit dem teuren...
Die Amerikaner wollten alle 300.000 Dollar haben pro Jahr und haben sich irgendwann gedacht, das können wir in Deutschland auch viel heftiger haben.
Genau, dann gehen wir halt in so ein Billig-Lonand und dann in so eine, keine Ahnung, Billig-Vorstadt und zwar gehen sie nach München.
Und wollen da ein neues Team aufbauen.
Da sind sie ja auch schon, da sind sie ja schon ein bisschen gewachsen.
Aber ich bin mal gespannt, ob das klappt, dass sie da jetzt irgendwie, keine Ahnung,
äquivalent rekrutieren können. Mal sehen.
Aber ja.
Ja, dann bestimmt er kann vor die guten Python-Leute sitzen.
Und wenn man in München guckt, die sind ja eh immer ganz oben, wenn man sie fragt.
Zudem gibt es keinen Lokal-Python-Rekrutismus hier auch.
Ja.
Genau, also das ist schon mal irgendwie, aber normalerweise ist das ja nie passiert.
Das ist ja immer so, mehr Python-Leute einstellen und so, voll gut.
und jetzt, und welche, hat man das irgendwie so rückgebaut? Das ist neu.
Vielleicht ist aber erstmal einfach nur so eine normale Glättung, die irgendwann mal ist, oder?
Ja, kann auch sein, ja.
Also vielleicht ist auch, muss man da nicht so viel reininterpretieren, das ist schon richtig.
Es gibt tatsächlich von Python 3.13 jetzt so erste Beta-Versionen.
Ja.
Das heißt, wenn man mal ausprobieren will, ob das eigene Zeugs, was man so baut, irgendwie damit tut,
dann kann man das jetzt mal machen und tut eigentlich, ne?
Ja, es gibt, glaube ich, jetzt auch, wo war das?
Irgendwas kann jetzt auch, man kann jetzt auch Reels bauen
für 3.13.
Ich habe es jetzt wieder, ich habe
heute echt keine Zeit gehabt, mich
die News nochmal anzugucken. Insofern tut mir
leid, wird etwas durcheinander, aber
ja, also genau. Python 3.13
kann man auf jeden Fall jetzt
mal so, jetzt ist der richtige Zeitpunkt, um das mal auszuprobieren.
Was habe ich noch?
Oh, ich habe gesehen, es gibt,
ich weiß aber nicht, ob das News ist, aber
es gibt ein Software-Development-Kit
für 1Password.
Also ich bin immer noch bei 1Password.
wie tut das zwar etwas weh, dass das alles super teuer ist
und so, aber ich finde es immer noch so
der beste Passwortmanager und
der hat jetzt auch ein Python
API im
Software Development Kit gekriegt, das heißt
man kann von Python aus irgendwie One Password
anfragen, also sozusagen man kann halt
Python Sachen schreiben und dann fragt
das Ding halt One Password und dann sagt das Ding
halt da, guck hier mal in die Kamera oder
hier, leg mal da deinen Finger drauf und dann kann man sich
authentifizieren, was ja für manche Sachen ganz nett ist.
Wie teuer ist denn das?
Weißt du das?
für meine Werbung machen.
Also OneCupBot
kostet, das ist wirklich, die haben ja auch wahnsinnig
viel Fremdkapital aufgenommen
und das kostet pro User
irgendwie sowas 35
Dollar oder Euro im Jahr ungefähr.
Und das ist halt schon
ja.
Und gab es Debatten, wie lange
ist der letzte Breach her?
Ja, es gab einen auch
über Okta,
der war aber nicht so furchtbar schlimm.
Also ist auch so ein halbes Jahr her, glaube ich.
oder so.
Ja, ich wollte gerade sagen, ich habe irgendwas im Kopf hier.
Genau, was haben wir noch? Ach so,
ja, es gibt auch gute Nachrichten, also
das ist ja auch so ein Ding, da kriege ich immer Angst, wenn ich mir
angucke,
wie das so funktioniert. PyPI
macht wahnsinnig viel Traffic.
Also was darüber geht, ist halt atemberaubend
und es kostet auch wahnsinnig viel Geld und das
funktioniert halt darüber, dass es einen
CDN, so Content Delivery Network
Anbieter gibt, der sponsert das halt,
der hostet PyPI.
und ich weiß nicht, was man zahlen müsste,
wenn man das nicht kostenlos
kriegen würde. Das wäre sehr viel und das wäre
ein Riesenproblem, weil
per Pivot installieren
würde dann halt nicht mehr funktionieren.
Und die haben jetzt gerade auf der
Python US
verkündet, dass sie
für fünf weitere Jahre
PyPI sponsern wollen.
Das ist natürlich praktisch.
Also es gibt noch mindestens fünf Jahre.
Ja, genau.
Dann tatsächlich
jetzt im Juni vor
zwei, drei Wochen
ist NumPy 2.0
erschienen nach irgendwie
14 Jahren
Entwicklungszeit.
Das war eine ganze Zeit lang
in Progress.
Und genau.
Ist vielleicht mal jetzt nicht der günstigste Moment
umzusteigen, sondern man sollte vielleicht
das jetzt mal auf kleiner 2 pinnen
oder mal gucken, bis alle anderen
sich angepasst haben, weil
das bricht halt einige
einige Geschichten.
Aber ja, schön, dass es jetzt raus ist
und dann macht einige
wie gesagt,
ich habe keine Ahnung, was alles genau
passiert ist oder ich wusste es mal, aber ich habe es wieder vergessen.
Ja,
Performance ist irgendwie besser geworden.
Es sind auch ein paar Updates, das heißt, ihr müsst ein bisschen aufpassen,
weil wenn ihr da irgendwie einfach updatet,
dann kann es sein, dass euch relativ
viele Dinge kaputt gehen. Also ich habe so ein paar
Updates gehabt, da war es so ein bisschen
hässlich, weil ich tatsächlich
und Jochen unterhalten sich über die Programmiersprache Python
erste 1.0 Release von Polos,
was ja auch vielleicht
ganz nett ist,
dass man sich jetzt halt so darauf verlassen kann, dass die
API da mal eine Zeit lang stabil bleibt und so.
Und da ist auch sonst nichts
Großartiges dazugekommen.
Nutzt du das irgendwo viel?
Nee, viel nutze ich das nicht. Ich nutze das ab und zu mal.
Hast du noch Pandas?
Ich nutze eher Pandas, weil ich mich halt da so an Pandas
gewöhnt habe. Nur weil du dich daran gewöhnt hast.
Ja. Aber Pandas haben die auch ein bisschen schneller gemacht.
Ich weiß gar nicht, gibt es irgendwie wirklich jemand, der das mal
getestet hat, was so für was
besser.
Ja, also Polars ist tatsächlich, wenn man
einfache Sachen macht, ist es halt ein gutes Stückchen
schneller.
Es gibt halt Dinge, die gehen mit Polars gar nicht so
und die gehen mit Pandas.
Viele Sachen sind halt auch total komisch
und ich habe mich halt daran gewöhnt, zum Beispiel an diese
Multi-Index-Geschichten und so.
Wahrscheinlich ist das keine gute Idee
und es ist richtig, dass Polars das alles nicht
gemacht hat und auch selbst die Leute, die Pandas gebaut haben.
Das weiß man, McKinney sagt heute
im Podcast so, ja, das mit diesen ganzen
komplizierten Index-Geschichten und so, das war wahrscheinlich
und Jochen unterhalten sich über die Programmiersprache Python
PsychoPG 2 explizit
und wenn man jetzt aber normal PsychoPG nimmt,
dann ist es jetzt normal 3.
Ja, genau.
Und ja, super, da ist halt auch
so Async Support
jetzt mit drin und
diverse Geschichten.
Auf Postgres 15,
was ist das Minimum für PsychoPG?
Warte mal, lass mal grad gucken.
Bestimmt noch bei Tifa.
Wahrscheinlich, ich würde jetzt tippen, Postgres 12
oder so.
Minimove steht da nicht.
Nee, steht, steht, ich weiß es.
Keine Low-Hand-Food. Okay.
Auch nicht so wichtig. Die meisten Leute,
sind die bei alten Datenbanken oder bei neuen? Was meint ihr?
Ich denke alte Datenbanken,
weil die meisten halt nicht die Kontrolle
haben über die Distributionen, auf denen
ihr Zeugs läuft und dann haben sie halt irgendwie
entweder alte Datenbanken,
weil Datenbanken auch oft nicht kontinuiert
sind,
oder
oder sie haben es konterinisiert
und haben dann vergessen, dass es irgendwie
was ist.
Aber ich sehe in der Praxis
ganz oft alte Daten machen.
Ja, stimmt.
Und ehrlich gesagt, ich finde es komisch, weil
das ist halt so, ich meine, das kostet eigentlich
ja nicht viel, das abzudaten oder da abzudaten
zu bleiben und es bringt halt ordentlich was.
Also eben, wenn ich jetzt mir
angucke, Postgres 12 oder so, was ich häufig
sehe oder
wenn man jetzt stattdessen
einen Postgres 16 nimmt, dann ist es halt schon
Da hat sich schon einiges getan.
Da kriegt man irgendwie so 30%
Performance-Proofment einfach so gerade.
Also, ja.
Genau.
Ja, dann
oh, HTMLX 2.0
ist erschienen. Auch ganz interessant.
Da hat sich auch nichts geändert, sondern das ist
einfach nur hochgezählt.
Und gut, es sind ein paar Sachen entfernt worden.
Also ein paar Extensions.
Die Websockers-Extension
ist nicht mehr drin. Oder ein paar Dinger.
Genau.
Ja.
Du benutzt es immer noch so gern?
Ich benutze es immer noch super gern.
Ich auch.
Ich habe es auch jetzt letztens wieder in einem Projekt gehabt und das war echt total super.
Wie würdest du denn einen Chat umsetzen?
Ja gut, okay, Chat, da muss man dann drüber nachdenken.
Vielleicht ist es da besser, dann was anderes zu nehmen.
Ja.
Könnte schon sein.
Ich meine, man kann es bauen.
Man kann, aber ob das so viel Spaß macht, weil da ist ja manchmal vielleicht Echtzeit dann tatsächlich,
und Jochen unterhalten sich über die Programmiersprache Python
ohne sowas machen, aber kann sein, dass Chat
eine der wenigen Sachen ist, wo man das halt tatsächlich braucht.
Ja.
Und das ist mit Chat mit dem Server?
Chat mit dem Server?
Also keine Ahnung, du schießt mit dem Server
eine Frage und nicht einem anderen
Menschen.
Ja, da brauchst du es nicht. Achso, du meinst jetzt sowas wie
Chat-GPT, wenn man das implementieren wollte.
Genau, da brauchst du es nicht.
Das geht Request-Response super.
Dann wartest du einfach drauf.
Ja, also du kannst halt dann,
kannst ja auch das anzeigen, was dann zurückkommt direkt.
aber da brauchst du keine
stehende Verbindung.
So gejankt jetzt, oder?
Ja, du kannst einfach
das anzeigen,
das geht.
Genau.
Genau, das ist auch sowas.
Dafür braucht man
keine
direktionale Verbindung,
keine stehende Verbindung.
Okay, dann
5.1?
Django 5.1 Alpha erschienen.
Genau, ich weiß nicht,
ob hier irgendjemand genau die Liste
der Neuigkeiten und so
mit dabei hat. Also ich meine, es dauert auch noch
ein Momentchen, bis das erscheint, aber...
Ist das die erste Alpha? Ja.
Also was ich hier schon sehe...
Ah, Query String, super. Das habe ich
hier halt schon ein paar Mal selber gebaut.
Warum gibt es das denn nicht?
Also das Problem ist, wenn man
quasi
ein paar
Dinge hinzufügen will zu einem Query-String,
zum Beispiel, wenn man irgendeinen Filter angeschaltet hat oder so,
dann ist halt die Frage,
okay, aber da sind ja jetzt möglicherweise
schon Sachen gesetzt und dann muss man das irgendwie,
ja, wie updatet man das hin?
Und da gibt es jetzt ein Template-Tag
für, wo man halt einfach
den Query-String kriegt und das ist natürlich praktisch.
Genau.
Ich hatte das Gefühl, dass da viel Quality-of-Life-Sachen dabei sind.
Nicht die großen Game-Changer, die sind jetzt eher
dann für 5.2, glaube ich, geplant.
Später mehr.
von eher Kleinigkeiten, die einem einfach helfen, besser und angenehmer zu arbeiten.
Ja, es gibt
Connection Pool Support für Postgres, was auch praktisch ist.
Also ich meine, ehrlich gesagt, für meine Sachen ist es nicht so, also da komme ich sowieso nie so
an die Grenzen, dass ich da wirklich ein Pool lieber hätte oder so, sondern
das ist alles egal. Aber wenn man das Problem hat, dann ist es natürlich doof,
wenn man da irgendwie was anderes tun muss.
Ja, ja, ja, ja, ja.
Middleware to require authentication by default.
Keine Ahnung, was das ist.
Aber ich würde sagen, über die ganzen Neuigkeiten bei Dango,
da können wir doch tatsächlich den Ronny gleich besser fragen,
weil der von Dango konnte wahrscheinlich mehr erzählen,
als er aus dem 5.1.
Ich glaube, das ist so wahnsinnig...
Ja, genau.
Ist auch nichts Weltbewegendes mehr.
Alles klar, dann haben wir nur ein Event, das das gibt.
Dann sind wir vielleicht mit der News heute schon ein bisschen durch,
oder habt ihr noch irgendwas, was ganz total relevant wichtig war?
Nicht von meiner Seite.
Okay, gut.
Dann erzähl doch mal von der DjangoCon, lieber Ronny.
Also ich hab ja, du, also erstmal,
du, eigentlich müsstest du ja von dir selber erzählen, weil du hast ja auch
was gesagt, glaube ich sogar, ne? Genau.
Und was Cooles erzählt und vielleicht fangen wir doch einfach damit an,
dann können wir danach so von allgemeinen Sachen erzählen.
Ja, genau. Also wie gesagt,
ich heiße Ronny, ich arbeite
seit 2012
mit Django. Ich hab damals mit
1.4 angefangen, was
lange, lange her ist.
Damals hatten wir auch noch ein anderes Versionsgeschäft
und Jochen unterhalten sich über die Programmiersprache Python
zu halten. Das habe ich dieses Mal das erste Mal
gemacht. Das ist das erste Mal auf einer
echten Konferenzstage. Ich war
man könnte vielleicht sagen zum
Warmlaufen letztes Jahr bei dem
Django Day in Kopenhagen. Das war sehr cool.
Das ist so eine Mini-Konferenz. Das ist so ein
Raum für so 60 bis 70 Leute, würde
ich sagen. Und das ist nur ein
Tag. Und das war sehr nett,
sehr familiär. Und
das war so das erste Mal, dass ich irgendwie
vor, naja, literally laufender Kamera
das gemacht habe. Das stimmt überhaupt nicht. Wir haben nicht schon ganz oft
live was erzählen hören. Ja, aber das
und Jochen unterhalten sich über die Programmiersprache Python
für Django gemacht habe. Das nennt sich
Django Pony Express.
Das löst im Endeffekt
das Problem, wer schon mal mit Django,
wir machen meistens, so von
meinem Job her, machen meistens Business-Applikationen
und meistens baut man da relativ
viele E-Mails.
Und E-Mails mit Django zu bauen,
das geht alles, das funktioniert auch technisch alles sauber,
nur die, ich mag diesen Begriff
sehr, die Developer Experience ist nicht
so richtig gut, weil man da relativ viel
Low-Level-Sachen machen muss, vor allem wenn man jetzt
nicht nur irgendeine E-Mail rausschicken möchte,
und Jochen unterhalten sich über die Programmiersprache Python
und HTML-Templates
oder Inhalte hatten,
Plaintext-Part-Inhalte, Übersetzungen,
bestimmte Header, bestimmte Variablen,
die für das Base-Template benötigt werden,
dass ich da nicht jedes Mal so riesige Funktionen hin und her kopiere,
sondern im Endeffekt wirklich nur drei oder vier Zeile
habe und die restlichen Sachen
an einer sinnvollen Stelle gekapselt sind.
Und ein zweites großes Problem, was mich
auch persönlich immer sehr gestört hat, ist,
dass E-Mails, weil die ja irgendwie so ein bisschen
eine externe API sind,
weil man schickt die irgendwie raus
und die kommen dann quasi vielleicht wieder bei mir an, wenn ich es mir selber schicke,
dass wir die nicht so richtig getestet haben,
weil es einfach auch mühsam ist und das Django-Test-Framework
bringt einem da so ein paar Tools mit, aber die sind alle so ein bisschen versteckt
und da habe ich dann so einen Wrapper gebaut,
der auch so ein bisschen, dass man diese E-Mail-Outbox,
wenn man E-Mails in einem Test verschickt, dann landen die in so einer Liste,
in einer Outbox, werden die gesammelt, dass die nicht aus Versehen rausgeschickt werden
an irgendwen und dass man auf diese Liste so ein bisschen wie
in einem Query-Set zugreifen kann, dass man kann nach Subject,
nach Inhalt filtern, man kann gewisse Assertions
machen, ob zum Beispiel in beiden
Content Parts, es gibt ja
mehr als nur HTML und Plaintext,
ob in den Context Parts da bestimmte Dinge
drin sind und so weiter.
Da habe ich einen Vortrag drüber gehalten,
das hat
sehr viel Spaß gemacht, ich war sehr nervös.
Ich kann sagen, du warst ja aufgeregt.
Ich war sehr aufgeregt, aber es hat sehr viel
Spaß gemacht tatsächlich. Ich war
unendlich viel schneller als bei den
Malen, wo ich geübt habe. Das ist glaube ich so eine Sache,
das ist man immer, aber ich war wirklich schnell.
Ich glaube, ich habe auf 21 Minuten Testzeit
16 Minuten Vortragszeit gehabt.
Ach, du hast wahrscheinlich geredet wie ich.
Ich weiß es nicht. Ich habe mir versucht, extra ein bisschen
Zeit zu lassen, aber
ja, hat so mittelgut funktioniert.
Nichtsdestotrotz auch viel
positives Feedback bekommen und
ist auch tatsächlich nochmal eine ganz andere
Art, auf so einer Konferenz
zu sein. Das war jetzt, glaube ich,
meine fünfte oder sechste DjangoCon
mit ein paar, ich glaube fünfte,
mit zwei Remote wegen Corona
und das ist echt nochmal ein ganz anderes Gefühl. Also ich finde generell, kann ich das jedem nur ans Herz legen, wer es noch nicht gemacht hat, geht mal auf eine Konferenz.
Auf meiner allerersten DjangoCon habe ich halt Uni-Styler erwartet, da steht irgendwer und erzählt was Langweiliges und dachte, ich gehe eigentlich wegen den Leuten dahin.
Tatsächlich gehe ich auch gerne wegen den Leuten dahin, jetzt wo ich auch viele kenne, aber die Vorträge sind auch wirklich gut und wenn man denkt, dass das halt auch alles auf einem kleinen Budget läuft,
und Jochen unterhalten sich über die Programmiersprache Python
Harnson Proposal. Ah ja, genau.
Dieses DEP, ich glaube, 14 oder sowas.
Die sind auch irgendwie in letzter Zeit erst wieder
entdeckt worden.
Ich glaube, dass es die gibt und die werden jetzt auch
wieder recht populär. Ich glaube auch
mit den neuen Fellows, Sarah und Natalia.
Und diese Background Worker
ist im Endeffekt eine Idee, dass man,
wenn man in einem Django-Projekt asynchrone
Ich glaube, da müssen wir
gleich noch ein bisschen genauer drauf eingehen, vielleicht so als
extra Thema, weil da haben wir vielleicht noch
zwei coole Links zu. Deswegen erzähl
gerne noch ein bisschen mehr zu deinem Talk über E-Mails.
auf die Backend.
Okay.
Ja, genau.
Also die...
Ja, was habe ich denn?
Was kann ich dazu noch sagen?
Irgendwie, war das
nicht auch irgendwas, wo so ein Architektur-Design-Pattern
irgendwie so ein bisschen eine Rolle spielte?
Oder...
Ne, vielleicht habe ich das auch einfach falsch.
Einfach nur objektorientierte E-Mails quasi.
Genau, und es ist halt
einfach ein Wrapper um die relativ
low-level-Api, wenn man halt
wie gesagt, ein bisschen
aufwendigere E-Mails bauen möchte.
Das war Sendmail mit ein bisschen Fluff.
Genau.
Bei Sendmail selbst, das erstellt ein
Python E-Mail Objekt, glaube ich.
Es gibt auch gerade eine große Diskussion
bei Python, dass scheinbar etwas
deprecated wurde in der letzten Version
und Django noch auf den alten Sachen.
Ich glaube, es ist nicht deprecated, dabei gibt es etwas Neueres,
Cooleres und die Django-Sachen
unter der Haube benutzen auch die alten
und dann ist gerade viel in Bewegung bezüglich
E-Mails. Interessanterweise, ich bin da
ganz aus Versehen auf diesen Zug aufgesprungen.
Das ist direkt eine blöde
Anwendungsfrage. Wie verschickt ihr denn E-Mails?
Also tatsächlich,
das ist auch eine Frage, die ich
jedes Mal gestellt habe, wenn ich diesen Vortrag, ich muss
gestehen, ich habe den an mehreren Occasions recycelt.
Das ist
eine Frage, die sehr oft kommt.
Bei mir geht es wirklich im Endeffekt
nur um die Developer Experience und um
die Maintainability. Also sprich,
wie erstelle ich programmatisch diese E-Mail, wie stelle ich sicher, dass da alles drin ist und wie kann ich das nachher testen.
Alles, was danach kommt, also im Endeffekt, das ist alles nicht das, wo das Package ansieht.
Also da hört es quasi auf.
Also bei den Unit-Tests, je nachdem wie man es definiert, ist quasi dann das Ende
und danach kann man halt dann die E-Mail so verschicken, wie man sie halt mit Django sonst verschicken möchte.
Also ob man da jetzt einen Mailhawk reinhängt oder irgendein super abgefahrenes E-Mailing-Cluster hat
oder seine eigene Gmail-Adresse dafür nutzt
oder einfach das bei
SES reinwirft.
Das ist nichts, was mein Package versucht
zu lösen. Wie macht ihr das?
Wir selbst nutzen SES.
Das ist von Amazon.
Ich glaube, das gibt es aber auch in,
das ist ein Standard sogar, ich bin nicht ganz sicher.
Ich glaube, Amazon hat ja viele von diesen Standards definiert.
Und das ist ein Service,
der ist halt sehr günstig und sehr
leistungsfähig. Ich habe für
ein Privatprojekt, ich
engagiere mich da für Kinder
in Bolivien, haben wir früher unseren Spendern und Interessenten so einen Jahresbericht per PDF geschickt,
das damals noch, bevor wir HTML-E-Mails hatten. Und diese PDFs waren immer so mit den Bildern,
auch wenn man die runtergerechnet hat, waren immer so 500, 800 Kilo beide, das ist schon relativ groß für eine E-Mail.
Und unsere alten Mail-Server sind regelmäßig da irgendwie abgekackt hängen geblieben, mühsam.
Dann habe ich irgendwann auf SCS umgestellt, alle E-Mails zu versenden kostet dann vielleicht einen Euro oder zwei.
und das läuft halt einfach.
Also du kannst dir eine beliebige Menge von E-Mails geben
und die kommen halt an.
Das ist halt sehr, sehr angenehm.
Genau.
Ja, und tatsächlich eine Sache kann ich dazu sagen,
was mich auch sehr gefreut hat.
Ich habe ja, wie gesagt, für den Vortrag auf der Core
ein gutes Feedback bekommen,
habe mich dann mit ein paar Leuten unterhalten
und habe ja noch ein paar Tipps bekommen,
weil ich halt in der Conclusion auch überlegt habe,
dass da Sachen drin sind,
die meiner Meinung nach auch gut in Django Core,
also in das Framework passen würden
und dass wir dort, dass ich mich freuen würde, halt was zu contributen, aber ich
habe bis jetzt halt noch nicht so die richtigen Sachen, das hat nie richtig
funktioniert, habe ich ein paar Tipps bekommen, wie ich das mache. Es gibt
nämlich ein Django-Forum, das wird es auch gerade noch ein bisschen, die
versuchen gerade so ein bisschen die Kommunikation da auch drin zu transitalisieren und da dann einfach meine Idee also mit etwas kleinem Anfang zum Beispiel dieser Testing Helper dass man halt quasi durch einen also dass man alle
textbasierten Medieninhalte
einer E-Mail, also in den meisten Fällen HTML
und Plaintext, wirklich einfach
gucken kann, ist dieser String da drin, also zum Beispiel
weiß ich nicht,
steht da drin, lieber Jochen als
Anrede oder steht da drin Auftragsbestätigung
oder ist da diese Auftragsnummer drin, solche
Geschichten und diesen Helper haben wir
dann in einem Forumsfeld ausdiskutiert.
Die Lösung, da haben sich auch sehr viele Leute beteiligt,
die Lösung, die rausgekommen ist, ist viel besser als das, was ich mir
alleine überlegt hatte. Es war viel
weniger zu implementieren, lustigerweise auch.
Was mal Leiner gemacht hat,
es gibt diesen schönen Spruch,
Weeks of Programming can save hours of
Planning. Das war wieder sehr wahr.
Und genau, dann
ist vor zwei Wochen, glaube ich,
dann das auch gemerged
worden in Django Core. Also in 5.2
habe ich meinen ersten Commit, was mich sehr freut.
jetzt nach zwölf Jahren.
Cool. Vielen Dank.
Genau.
Ja, das klingt cool.
Ich muss es eigentlich auch mal ausprobieren. Ich hatte das zwischendurch
mal so angeguckt, aber nicht dann angefasst, weil
die E-Mail-Lösung bei mir war schon fertig
und ich hätte hier alles rüber müssen.
Ja, ich kenne das.
Aber eigentlich, für das Template wäre es eigentlich cool, das drin zu haben,
weil das klingt danach, als müsste man das
an verschiedenen Stellen schön benutzen können.
Weil halt auch, wie du gesagt hast, diese ganzen Features,
Templates per
HTML und so weiter,
sehr gerne genutzt werden.
Tatsächlich ein Feature, was ich persönlich sehr mag,
einfach so ein Convenience-Feature,
de facto interessiert
die wenigsten Leute wirklich der Plaintext-Part,
weil die normalen, die modernen E-Mail-Clients
oder die Web-basierten Clients
den eh nicht anzeigen. Das heißt, die einzigen
Arten, wo man das sieht, ist, wenn man
so ein E-Mail-Client hat, dann geht so ein Pop-up auf,
das nimmt meistens den Plaintext-Part
oder wenn halt irgendjemand auf seinem
Linux-1980
konsolenbasierten E-Mail-Programm noch
und Sitz. Da gibt es auch so ein paar Spezies, die das machen.
Aber ansonsten sieht es halt niemand.
Und ich habe mir mit einem externen
Package, als Default
rendert der einfach das HTML-Template
als Plaintext und tauscht dann halt die Tabellen
durch Pipes und sowas. Die Struktur ist nicht
schön, es funktioniert. Auch Links und sowas
kriegt der hin. Also das kriegt dann
quasi wieder der
Client dann hin, der das
dann auch trotzdem auf Plaintext
meistens zumindest dann wieder irgendwie
interpretiert. Und das ist sehr angenehm,
weil dann hat man keine doppelten Templates mehr und das ist
natürlich schon ein Problem, dass man durch diese doppelten Inhalte
wie zum Beispiel bei uns in einem Projekt, wo wir gearbeitet
haben, hatten wir bestimmt 50
verschiedene E-Mails, alles mögliche,
um halt den Kunden zu informieren, was so mit
seinen Dingen passiert ist.
Und da wurde ständig vergessen, eine von beiden
Teilen anzupassen. Das kann man natürlich in gewissen Maßen
durch diesen Testhelper
lösen, dass man das einfach unit testet.
Nichtsdestotrotz, wenn es ein Rechtschreibfehler oder sowas ist, hat man
vielleicht darauf gerade nicht geschaut. Das war
ein ständiger Pain und das
kann man sehr gut damit halt einfach
erschlagen und löst
das Problem damit. Das ist sehr angenehm.
Sehr gut. Und du hast
gesagt, er macht auch sowas dann wie
Opt-Outlinks oder
E-Mail-Newsletter oder sowas dann direkt
mit drin. Ist das da in einem Package drin?
Also das Package nicht. Die Idee ist
quasi, dass man, also diese,
dass man, also ich biete quasi
also das Package, nicht ich,
nicht ich persönlich, biete so eine
Basisklasse und wenn man von dieser Basisklasse
erbt, dann kann man halt
dann eine E-Mail definieren, kann ein paar Attribute setzen,
zum Beispiel das Subject setzen,
das Template setzen, gegebenenfalls noch
Kontextvariable mitgeben, zum Beispiel den Auftrag
oder den Link oder irgendwas, was halt
der Inhalt der E-Mail ist.
Jetzt hat man aber natürlich oft
einfach so, also die E-Mails, die man
schickt aus dem System, sollen ja irgendwie
einheitlich sein. Du hast, wie auch
bei der Webseite, hättest du ein Basis-Template.
Du hast das Logo oben drin, du hast
vielleicht eine generelle Anrede, du hast ein
Footer, wo ein paar legale Sachen drinstehen, wo
vielleicht ein Unsubscribe-Link drin ist und
diese ganzen Sachen,
die ganzen Informationen, die man dafür braucht,
das sind auch die dynamischen Sachen, zum Beispiel
wenn man sagt, der Unsubscribe-Link enthält ein Hash oder sowas,
dass der Nutzer identifiziert werden kann,
der das draufgeklickt hat und solche Geschichten.
Wenn man da einfach von der
meiner Pony Express Basisklasse
ableitet, eine eigene Basisklasse macht,
dort dann halt die zum Beispiel die
GetContextData, wer Django kennt, weiß, was ich meine,
überschreibt,
dann kann man da halt einmal die ganzen Sachen definieren.
Oder zum Beispiel, dass man Subject-Prefix hat.
und ich persönlich finde, es sieht immer schön professionell aus,
wenn alle E-Mails, die vom System kommen,
halt irgendwie geprefixed sind oder zum Beispiel dann irgendwie
meinwebshop.de
minus und dann halt Account erstellt, Passwort
reset und was auch immer. Und diese Sachen kann man
einmal definieren und jede E-Mail, die man dann
weiter erstellt, leitet dann halt von dieser eigenen
Klasse ab. Und das,
ich meine, das ist halt ganz normale Objektorientierung, das hat
nichts mit dem Pony Express zu tun,
aber das macht es sehr angenehm und führt
auch dazu, dass die eigentlichen E-Mails, die ich
am Schluss dann, wo ich dann auch die
Ente
implementieren muss,
dass das wirklich dann meistens
halt nur zwei oder drei Zeilen Code sind.
Was es natürlich auch viele sehr angenehm macht,
neue E-Mails
hinzuzufügen.
Genau.
Cool, cool.
Hast du da so White Label Templates dabei, die quasi gar nichts
vorgeben, aber die es schon gibt, die man einfach benutzen kann?
Also ich tatsächlich, wenn ich
das mache, ich fange immer an mit einer
Google-Suche nach Responsive E-Mail Template,
da lande ich immer bei dem gleichen GitHub-Repo,
und Jochen unterhalten sich über die Programmiersprache Python
und Python-Browser. Vielleicht ist es auch einfach okay, wenn dann der eine, der halt noch den Explorer 11 nutzt, wenn das dann die Webseite halt nicht perfekt aussieht. Von daher, das ist auch wie gesagt ein Thema, auf das ich mich gar nicht fokussiert habe, weil ich versucht habe, nicht zu viele Probleme in einem zu lösen. Ich habe selbst überlegt, ob ich diese Sache mit den Class-Based E-Mails und die Sache mit der Test-Suite, ob ich die auseinanderziehen soll, weil es ja im Endeffekt die Test-Suite einen eigenständigen Nutzen hat, auch wenn ich keine Class-Based E-Mails verwende. Das ist einfach nur ein Django-Ding.
und man soll ja Packages eigentlich immer
so bauen, dass die nach Möglichkeit genommen
ein Problem lösen, weil es dann einfacher zu verkaufen,
einfacher zu verstehen ist.
Von daher habe ich mich auch entschieden, dann da nicht noch
weitere Dinge reinzubauen
und auch persönlich, weil ich da halt auch nicht so
die Pain-Points hatte.
Also hast du eh schon
immer Copy-Paste, musst es aber erst nicht bereitstellen mit den Packages.
Genau.
Ja.
Klingt gut.
Aber jetzt kommen wir tatsächlich, glaube ich, dann zu
Django Tasks, weil, wenn man ihm es verschicken
möchte, möchte man das ja wahrscheinlich
nicht sequenziell.
Genau, nicht dem Main Thread.
Und genau,
da gibt es ein neues
Konzept, wie gesagt, das nennt sich
Background Workers, das lebt aktuell in einem Package
namens Django-Tasks,
da muss man aufpassen, es gibt ganz viele, die ähnlich klingen.
Django-Background-Tasks,
ja, Background-Tasks-Manager, ja.
Genau, auf jeden Fall dieses Django-Tasks-Package,
das ist von Jack Howard, der hat das jetzt relativ schnell
zusammengenagelt, das ist echt erstaunlich.
Der freut sich auf jeden Fall über
dass du nicht Django Background hast
Ja, ich merke schon
ich google hier
Der freut sich auf jeden Fall
immer über Leute, die das ausprobieren, also wer von euch
Interesse an Django hat
möge das gerne anschauen, jetzt muss ich noch einen Satz
sagen, was das überhaupt ist
Genau, die
also in den meisten Projekten
wenn man irgendwas asynchron machen möchte
da meine ich es gar nicht dieses
relativ moderne Async, sondern einfach
Ich möchte irgendwelche Prozesse nachgelagert machen, zum Beispiel
irgendeine große Berechnung machen,
irgendeinen Cache befüllen oder halt auch eine E-Mail
schicken, weil ich möchte ja mit dem E-Mail,
ich muss ja mit der externen API kommunizieren,
um die E-Mail zu versenden, dann möchte ich ja im Optimalfall
nicht meinen externen Thread blockieren,
meinen Main Thread blockieren.
Und
genau, deshalb
gibt es in jedem
Projekt, in dem ich gearbeitet habe,
irgendeine Art von asynchronen
Processing, meistens in der Form von Celery.
Das ist in der Python-Welt sehr bekannt, in der Django-Welt sehr gehasst und gefürchtet.
Gibt es Django-Queue oder Queue-To?
Das ist jetzt aufgekommen, das ist so eine leichtgewichtigere Alternative,
weil das Hauptproblem ist, dass Celery erzwingt, dass man irgendeinen Broker dazwischen stellt,
der als Message-Queue dient.
Man kann das auch so konfigurieren, dass der direkt die Datenbank nimmt.
oder der hat eine lokale Datei, in der er irgendwas reinschreiben kann
und macht irgendeine SQLite noch extra auf.
Okay, das weiß ich.
Ja, aber ich glaube, man muss es nicht unbedingt.
Also das ist üblich, ja.
Und es ist auch, also ich habe das mehrfach
schon gesucht und
für die Result-Backends, also bei
Celery, wenn quasi um die Ergebnisse zu speichern
und das im Endeffekt so eine Art Log,
was passiert ist, dafür geht
das. Das ist relativ einfach, aber für
den Broker selbst bin ich zumindest immer
damit gescheitert. Ich war tatsächlich nie so
viel investiert darin. Auf jeden Fall
für die allermeisten Cases ist es halt einfach
harter Overkill, wenn man da halt irgendeine Postgres oder
MariaDB hat. Die kann in den,
zum Beispiel bei uns in den meisten Fällen, kann die paar
hundert Tasks, die am Tag laufen,
problemlos abfrühstücken,
ohne dass sie da irgendwie in Verlegenheiten kommen.
Selbst bei ein paar tausend Tasks ist es immer noch
kein Problem. Vor allem, wenn man dann vielleicht
auch sagt, dass
der große Task vielleicht auch eher
nachts läuft für irgendwelche Sachen,
da ich auch keine Userlast habe.
Und das wird allgemein sehr
stark als Overkill angesehen dazu, wie Dominik
gerade schon gesagt hat, viele Leute fürchten auf
Celery aus verschiedenen
Gründen.
Das ist dann auch kaputt eingestellt.
Aber vielleicht ist die Frage auch, ob es an Celery liegt oder daran,
dass Async halt ein bisschen schwieriger ist.
Also da würde ich gerne
nochmal kurz eine Begriffsklärung machen, weil
viele sagen ja Async,
und ich höre auch immer, wenn von Async
geredet ist, dass dann Leute sagen so,
das merke ich dann
irgendwie nach einer gewissen Zeit, dass Leute eigentlich so etwas
wie Celery meinen, aber das
hat ja jetzt mit zum Beispiel
Async.io oder so, damit
überhaupt gar nichts zu tun ist, das ist ganz anderes.
Ja, also Tenor ist ein eigener Worker-Prozess,
natürlich, ich verstehe die halt einfach sehr
Tastacharbeit zu einer bestimmten Zeit, weil die halt in der Liste stehen
und dann also diese Queue leert.
Du hast eine Anzahl von Workern
und hast halt irgendwie
genau
ein Ding, das halt eventuell auf so einer Queue
drauf sitzt und dann verteilt es halt Jobs an
diese Worker und die machen dann halt
Dinge und schreiben ihre Resultate wieder
irgendwo hin.
Ja, und genau
Ich glaube, warum die Leute denken, dass es Async ist, weil das halt meistens
wie schon gesagt, nicht im Main-Prozess läuft
obwohl man das auch machen kann, du kannst ja mit Django mitstarten
oder so, aber die Frage ist auch da
was das halt heißt, also weil
Jochen weiß das bestimmt besser, weil es ja irgendwie
verschiedene Event-Queues, die man nutzen kann
G-Event oder Event oder irgendwas
Nee, nee, gar nicht, damit hat es überhaupt nichts zu tun
also mit G-Event oder sowas hat es überhaupt nichts zu tun
G-Event ist sowas wie Async.io, ganz anderes
Aber kann man machen, also wenn man das mit Django selber macht
dann muss man sich überlegen, welche da benutzt wird
Ja, aber nicht sowas wie G-Event oder auch nicht sowas wie Async.io, gar nicht.
Also das ist einfach was ganz anderes.
Das ist auch nicht eine Geschichte, die im gleichen Prozess normalerweise stattfindet,
sondern du hast halt tatsächlich andere Prozesse.
Ja, wenn man die hat, genau, wenn man die anderen Prozesse hat, dann schon.
Anders geht das nicht.
Okay.
Also, genau, anders geht anders.
Jedenfalls nicht, dass ich wüsste, dass das irgendwie anders gehen würde,
weil wie soll das funktionieren, wenn du halt jetzt irgendwie, keine Ahnung,
und nehmen wir an, du stößt halt an in einem Request, also du hast halt irgendwie einen Button, das steht drauf Send E-Mail, drückst auf E-Mail
und wie soll das jetzt gehen, dass dann eine E-Mail, ja so vielleicht geht es tatsächlich irgendwie, aber das ist alles sehr hässlich.
Also du willst eigentlich einen Task dafür starten, der ganz woanders ist.
Du hast recht, du willst das auf jeden Fall, da würde ich auf jeden Fall zustimmen.
Definitiv.
Ja, aber diese beiden Dinge haben eigentlich nichts miteinander zu tun.
auch. Wenn man das eine für das andere vielleicht so halb
irgendwie verwenden kann, aber nee, das ist
eigentlich was ganz anderes.
Wie gesagt, es ist halt,
also wenn du quasi auf den
Main Thread schaust, dann läuft es halt
irgendwie nicht da drin, von daher liegt es halt
nahe, das irgendwie asynchron zu nennen,
auch wenn es mit dem Python Async
natürlich nichts zu tun hat, technisch.
Ja.
Genau, aber es läuft halt nicht
irgendwie Async, oder in einem
anderen Thread, sondern es läuft in einem anderen Prozess.
Also hat überhaupt gar nichts mehr mit dem
zu tun, mit dem der Interpreter da läuft.
Also, ja.
Genau.
Genau, und insgesamt, das Celery-Setup ist halt auch
relativ, es ist halt, da schießt
man wirklich schon auf,
also mit sehr großen Kanonen, weil ja
meistens man dann mehrere Worker hat, man hat einen Beat,
der für Scheduling, also der im Endeffekt
diesen Contab dann ersetzt.
Dann gibt es noch dieses Monitoring-Tool
Flower, was so
mittelgut funktioniert und eher
schlecht als recht meiner Meinung nach gewartet
ist. Nichtsdestotrotz, wenn man mal irgendwie
reingucken möchte, hilft es schon. Dazu
kommt halt noch, dass man meistens
halt dann diesen Message Broker
braucht, der halt dann
meistens ein Redis oder ein RevitMQ
oder ein Derivat davon ist
und das ist halt für viele Projekte
vor allem am Anfang ist das halt enormer
Setup-Aufwand. Wer das
erste Mal in seinem Leben Celery
einrichten muss, der wird daran keinen Spaß
haben.
Wenn du halt zum Beispiel auf das Redis sonst nichts anderes benutzt
oder sowas, das läuft halt die ganze Zeit rum.
Genau, und es bläht das Setup halt enorm auf und es ist jetzt halt, seit scheinbar auch Jahren ist es halt irgendwie allen bewusst, dass es halt schon cool wäre, wenn Django da selber was könnte und man halt eben nicht mit Celery kommen muss. Wie gesagt, die Popularität von Django Q oder Q2, wie der Nachfolger davon heißt, der ist ja tatsächlich jetzt auch nicht aus der Welt, weil der im Endeffekt wirklich sehr, sehr leichtgewichtig einfach nur halt Dinge irgendwann außerhalb in einem anderen Prozess abarbeitet.
und die Idee von Jack Howard ist jetzt,
das wirklich in Django zu integrieren.
Er hat erstmal ein Package gemacht, wie man das
halt optimalerweise auch so macht, dass Leute es auch
separat testen können und
das Ganze hat er vorgestellt.
Das war,
ich weiß nicht, ob es wirklich eine Keynote war,
aber es war auf jeden Fall de facto eine Keynote. Ich glaube,
das war das, wo die Leute am meisten
und am heißesten drauf waren.
Und das ist sehr spannend, weil
ich tatsächlich auch bei mir in meinen
diversen Projekten, glaube ich, auch einfach aktiv
zurückbauen würde, weil
und Jochen unterhalten sich über die Programmiersprache Python
interessant war. Ich habe
der Talk von Carlton Gibson
ging im Endeffekt um mal wieder
HTMLX ist super und mit AlpineJS kann man
zusammen coole Dinge machen.
Und sein Treiber davon war, dass er halt sagt,
dass jetzt, wo wir in einer Zeit leben,
wo die Zinsen seit langer Zeit wieder
ein bisschen höher sind, Venture Capital
deutlich seltener
geworden ist und deutlich
in kleinere Mengen vergeben wird.
Und dass deshalb
dieses, ich habe ein Startup und ich möchte
irgendwas ausprobieren, dass die einfach mit viel
und Jochen unterhalten sich über die Programmiersprache Python
zu klein als zu groß.
Und das ist
interessant, weil
das, ja, ich meine,
wird ihm vorher auch schon klar gewesen sein, aber das nochmal so auf den Punkt
zu bringen und dann zu sagen,
ja, genauso sehe ich das auch, weil, ja, natürlich
kannst du, wenn du mit React oder Vue
kannst du ausgefallene
Reformen bauen, kannst du mehr Dinge tun.
Die Frage ist, brauchst du das
und schaffst du das in dem Geld, das du hast?
Und das, finde ich, ist halt so der
spannende USP da dran.
Klar, wenn man erstmal seine
komplette Applikation mit HTMLX ohne API gebaut
und irgendwann kommt einer und sagt, ich möchte das jetzt alles anders
haben. Das ist natürlich auch nochmal teuer.
Also ich glaube, man muss da auch ein bisschen in die
nicht nur sagen, wie viel Geld haben wir jetzt, sondern wo geht
das Ganze hin. Nichtsdestotrotz
persönlich finde ich das auch sehr
spannend. Der Talk war auch sehr cool und sehr
energetisch, wie Carlton Gibson halt immer so
ist. Genau,
war echt super spannend.
Ich glaube,
dieses Django-Template-Partials kommt
halt auch irgendwie jetzt, ich weiß,
rein. Ich weiß nicht, ob das schon bei 5.1 war oder doch eher 5.2, wahrscheinlich eher 5.2.
Oder hat er auch über
dieses Neapolitan-Ring gesprochen, was er da
das ist ja auch so ein... Neue Crud-Views oder so. Ja, genau.
Also das dreht sich alles um diese Idee des Locality of Behavior.
Carlton Gibson hat jetzt vor nicht allzu langer Zeit einen Newsletter
angefangen, Stack Report heißt der, wo er einmal im Monat sehr ausführlich
zu einem Thema schreibt. Ich habe den abonniert.
Das kostet, glaube ich, irgendwie 5 Euro oder so was.
Bis jetzt hat es sich, also
ich glaube, es gibt es erst seit 2-3 Monaten,
bis jetzt hat es sich gelohnt. Also ich mache da gerne auch nochmal Werbung
für ihn, unbezahlt.
Das finde ich echt cool.
Also es war echt interessant.
Er hat jetzt über diverse Dinge da geschrieben
und in dem aktuellen von diesem Monat ging es halt
um Locality of Behavior.
Und er versucht halt im Endeffekt das Konzept
zu verkaufen. Also er sagt halt, dass wenn
alles, was du brauchst, in einer Datei steht,
ist es halt einfacher zu verstehen.
und er argumentiert nicht,
dass man alle guten Principles,
die man gelernt hat, sofort wegwirft,
sondern dass man halt dieses Premature Optimizing
aufhört, dass man sagt, okay,
ich fange jetzt schon mit, weiß ich nicht,
die, die, die an und mache das alles perfekt in
vielen Dateien, ein Neueinsteiger in dem Projekt
hat keine Chance zu verstehen, was eigentlich
passiert, sondern fangt erstmal klein an
und refactet, wenn ihr es wirklich braucht.
Weil viel von dem, ah ja, ich brauche es
nochmal, ich mache das mal irgendwie woanders hin,
kommt dann nachher mit, naja, ist doch
irgendwie anders geworden, war doch nicht so, wie ich es mir
gedacht haben und dann hat man halt immer diese doppelte
Refactoring-Schleife und dieses
Django Template Views ist halt die Idee
Django Template Partials
Sorry, Partials
dass man halt wirklich sagen kann, okay
diesen Block kann ich jetzt mit HTMLX neu
rendern lassen, der ist aber trotzdem noch in der
großen Datei und ich muss es nicht zerpflücken, wie man es
halt vorher, also Stand jetzt mit
Vanilla Django macht
und diese Neapolitan
Crud Views ist auch die Idee, dass du halt wirklich mehr
Sachen an einer Stelle zusammen
hast. Dass man im Grunde eine Klasse hat, wo die
also GetPost und sonst wie Dinge, die da passieren, halt alle drin sind.
Ich persönlich finde, dass Locality of Behaviour ist, glaube ich, eine gute Sache.
Ich meine, das geht auch so ein bisschen nach Yagni, also you ain't gonna need it.
Dass man halt nicht, dass man erstmal überlegt, so muss ich jetzt wirklich anfangen,
alles so hoch zu skalieren, wie es unbedingt notwendig ist.
Nichtsdestotrotz, wenn ich weiß, ein Projekt wird eine gewisse Größe erreichen,
die Dinge zu tun, die ich jetzt schon weiß, die sinnvoll sind,
glaube ich, dass man sich da dann andererseits
auch wieder ein paar Refactoring-Zyklen spart.
Aber ich glaube, generell ist man schon
sehr prone, als Entwickler over
zu ingenieren und ich glaube, das sich im Kopf zu behalten,
so muss ich das jetzt wirklich tun.
Also so ein Trade-off mit KISS
oder sowas, schon simpel und dass du irgendwie
tatsächlich versuchst, vielleicht, also
was ich zum Beispiel finde, ist, dass wenn halt zu viele Sachen
in einer Datei drinstehen, selbst wenn das irgendwie
am Anfang überblicklich ist, wird es halt auch dann wieder hässlich.
Und wenn eine gute Modulstruktur
darunter liegt einfach, also einfach nur
vom Namespacing, hilft das
fast am meisten, finde ich.
Was dann auch gar nicht schwer
zu verstehen macht, wenn das halt alles in einem Director liegt,
zum Beispiel, dann ist das schon vielleicht ein bisschen näher dran.
Aber wenn das Director in einem Gruß wird, dann ist das
wieder ein Problem.
Oh, ich würde
ganz kurz nur einmal kurz
einwerfen, nochmal zu dieser
Task-Geschichte, was ich halt oft sehe,
was ich finde, was man vermeiden sollte,
wenn Leute
sowas machen und das halt irgendwie, weil
oft macht man das dann ja,
Man braucht es schon meistens, aber dann doch nicht
irgendwie so dauernd, dass
alle Leute da irgendwie
viel Erfahrung mit hätten.
Und was ich jetzt schon häufiger gesehen
habe und was in der Praxis dann so
zusätzlich zu diesem ganzen
Infrastrukturding auch nochmal ordentlich Schmerzen macht,
ist halt, wenn Leute anfangen,
irgendwie so ganz Kaskaden von Tasks
irgendwie zu schreiben.
So gerade bei Celery ist das dann halt auch
sehr einfach. Und dann hat man da Abhängigkeiten
dazwischen und dann
und Leuten ist gar nicht so bewusst, dass es bedeutet,
ja, das geht jedes Mal über eine Prozessgrenze,
dann wird da irgendwie wieder irgendwas wieder realisiert,
dann muss der ganze Rahmen wieder so rausgelegt und realisiert werden,
dann geht es irgendwo zwischendurch schief
und dann hast du halt irgendwie so ein
explodiertes Gedärm irgendwie,
was dann rumliegt.
Also was ich nur
empfehlen kann, ist, man macht halt eine
Funktion oder so eine Methode an irgendeinem Modell
oder so, wo man halt das, was man tun möchte,
halt reinschreibt und dann testet man das ganz normal,
synchron,
irgendwie, wie man
Sachen halt so testet und dann sagt man
in einem Celery-Task
eigentlich nur, okay, man ruft halt dieses Ding auf, fertig.
Wie man auch
im Vue schreiben würde, möglichst schlank und
eigentlich nur die Dinge
komponieren, denn wirklich da implementieren.
Ja, und keine Logik in die
Tasks parken, sondern
von den Tasks, also in den eigentlichen
Celery-Tasks immer nur irgendwie Logik, die
irgendwo anders ist, aufrufen. Aber wenn du halt
im besten Logik verteilt über mehrere Tasks,
dann passieren scheröckliche
Dinge unter Umständen.
Absolut.
Genau, das war nur so ein kurzer Einwurf.
Es gab da noch
so ein tolles Thread zu
im Chaos Social,
den du auch den Link vorhin geteilt hast.
Das ist sehr, sehr interessant.
Einige coole Leute, unter anderem
Carlton Gibson selber und Hüneck und so.
Ja, Hüneck, genau. Und diverse Leute,
da gab es ein Thread zu,
was braucht man jetzt bei Background Tasks eigentlich alles?
Ja, genau. Und was sind da die Anforderungen
genau? Und das ist auch in der Praxis.
anders implementiert. Und auch alle haben sich über Celery
beschwert aus Gründen.
Ja, ich kann mir genau das Ding verlinken.
Ja, Fettyverse ist halt
zur Zeit, also wenn er noch nicht ist,
da sind halt alle...
Das steht tatsächlich auf meiner Liste und ich lese halt immer
so ein bisschen mit, aber naja.
Ja, also das fühlt sich an wie
Twitter früher, so ein bisschen
Blümchenwiese-mäßig, weil alle
Leute oder viele der Leute,
die man so kennt, sind da und
man kann sich mit denen einfach so
unterhalten und so.
Ja, cool.
und Jochen unterhalten sich über die Programmiersprache Python
reagieren die Leute? Was für Sachen werden wirklich
angefragt? Das finde ich halt sehr interessant,
weil ich glaube, das ist einfach so ein generelles Ding.
Wenn man irgendwie in der Softwareentwicklung ist, dieser MVP-Gedanke
ist so, so, so zentral
und da kann man so viel falsch machen,
so viel Geld und Projekte und Chaos
verlieren, wenn man
halt nicht dem MVP denkt.
Weil schöner geht
halt immer und
ja, genau.
Ja, und genau,
bei Ruby on Rails ist halt
auch diese Background-House-Geschichte schon
seit Ewigkeiten drin.
Und das war immer eine der Geschichten, die in Django
halt, ja, wo man da halt irgendwie dann
immer sagen musste, ja, nimm halt Terry.
Ja, es tut weh. Nimm's halt trotzdem.
Das ist das, was es gibt.
Ja.
Und wenn sich das jetzt
ändert, dann ist auf jeden Fall ein Painpoint
irgendwie auch weniger.
Sie haben gesagt, dass wenn es gut läuft, landet das
in 5.2. Du weißt, wann 5.2
rauskommt, hattest du gesagt?
April, ja.
Genau.
Dann wird dann neben meinem kleinen Testhelper
das zweite große Ding,
wenn du dann die Background hast
Sehr gut, sehr gut
Genau
Ja, also
HTMLX war diesmal auf der DjangoCon
also auch quasi wieder so ein, es ist ja die letzten
Male eigentlich immer ein großes Thema gewesen
Genau, ja ich meine
HTMLX ist halt im Endeffekt die Silver Bullet mit der sehr sehr viele Leute dann HTMLX vermeiden k HTMLX JavaScript vermeiden k was nat so ein bisschen
Gänsefüßchen ist, aber natürlich immer noch ein bisschen
JavaScript braucht und das auch sehr viel mit JavaScript geschrieben ist.
Nichtsdestotrotz
vermeidet das halt, dass man in Projekten
JavaScript verwenden muss,
was natürlich für viele tendenziell eher
Backendler, wie ja Django aktuell
verwendet wird, weil es ja auch ein sehr data-driven Framework ist.
Das ist
natürlich sehr angenehm, da zähle ich mich auch dazu.
Ich habe es auch irgendwie nie geschafft,
mich ernsthaft mit einem
JavaScript-Framework zu beschäftigen und
ich bin
auch in meinem Beruf immer wieder damit konfrontiert,
bei den Entscheidungen, wenn man
ein neues Projekt startet, was nehmen wir jetzt?
Wir haben es jetzt tatsächlich bei dem letzten Projekt, das gestartet ist,
auch aktiv für HTMX entschieden.
Auch mit einem Team, die tendenziell
eher auf JavaScript-Front-End
sind.
Das ist ganz interessant.
Weil wir einfach auch gesagt haben,
Beglauers, da ist immer halt, dass das Projekt ist halt
so eine ganz klassische Backend-Ableck,
man hat viele Listen, man hat viele Crud-Views,
es gibt zwei, drei, vier Sachen, die so
ein bisschen ausgefallen sind, aber auch nicht so
wirklich, also da hat man mal so ein Drag-and-Drop-Element
oder sowas und
wir sind aber der Meinung, dass
man das dafür halt HTMX
wirklich gut funktioniert, weil das ist das, was Django
wirklich gut kann.
Und das
Projekt ist es auch nicht etwas, wo man sagt,
das ist jetzt irgendwie,
wenn die Firma durch die Decke geht, dann
so und so, sondern das wird immer eine Backend-Applikation
bleiben. Logischerweise wird die wachsen,
wenn die Firma wächst, etc.
Aber das wirkte einfach nach dem
perfekten Hammer für diesen
Nagel, was nicht heißt, dass
wenn man jetzt sagt, ich möchte es, keine Ahnung,
das nächste Instagram oder sowas bauen,
dass das vielleicht, wenn man schon die Kohle dafür hat
am Anfang, dass das vielleicht nicht
unbedingt die beste Wahl ist. Geht wahrscheinlich
auch alles trotzdem, aber
ich glaube, umso mehr, sag ich mal,
wirkliche Endnutzer, also jetzt nicht Mitarbeiter
der Firma oder Administratoren, so mögliche Endnutzer
man auf der Plattform hat, wahrscheinlich schwingt da
dann immer so die Notwendigkeit für
ein richtiges, volles Frontend-Framework,
wo man das ja auch in Gänzefüßen sehen muss,
React und Vue sind ja auch keine Frontend-Libraries,
schwingt dann doch eher
so das Pendel in diese Richtung.
Und ich glaube, diese Frage kann man
halt wie jede einzelne Tech-Frage
damit beantworten, es kommt drauf an.
Nichtsdestotrotz wird das
natürlich hart gefeiert in der Community, weil
wie das auch bei mir so ist, das ist es halt,
ich bin seit zwölf Jahren dabei,
das erste Mal, dass
ich jetzt wirklich
ein Werkzeug bekomme, das
vernünftig funktioniert. Und das, was
man früher so immer gemacht hat, wie JQuery und sowas,
definiere ich nicht als
vernünftig funktionieren.
Also man kommt damit
erstaunlich, aber das hat nie wirklich gut
funktioniert.
Wobei ich eine Sache
hinzufügen würde, etwas, was ich in letzter Zeit auch
häufiger mache und wo ich auch denke, oh, das ist
auch alles gar nicht schlecht und es geht in die richtige Richtung,
sind halt so Web-Components.
Das ist eigentlich auch ganz nett.
Da muss man dann halt JavaScript schreiben. Das ist halt so ein bisschen doof.
Aber man kann
halt irgendwie, das hält sich dann halt
in Grenzen. Und man
weiß halt, das habe ich letztens
wieder erlebt und das tut jedes Mal weh,
größere Projekte,
die man lange nicht angefasst hat,
das ist immer schmerzhaft.
Also wenn man jetzt irgendwie
da so, zum Beispiel das war jetzt
mein View-Projekt, es ist halt
irgendwas geht nicht mehr
und es dauert immer, bis man rausgefunden hat,
was denn da jetzt eigentlich das Problem ist und bis das alles
wieder rund läuft und dann
vergehen vielleicht auch noch mal ein paar Tage oder
Wochen, bis man wirklich alles gefunden hat, was vielleicht nicht mehr
ging, weil manchmal war es das nicht so offensichtlich
und das ist einfach total nervtötend.
Also und
genau, das Problem hat man mit Web Components
halt auch nicht, weil das ist halt Standard und
wenn das jetzt funktioniert,
funktioniert das in 10 Jahren
halt auch noch ganz genauso und
ja.
Tatsächlich haben wir jetzt in dem Projekt mal Django Components
ausprobiert, das ist ja auch eine von diesen vielen
ansetzen, da gibt es ja auch Django Slippers und wie die alle heißen,
um
im Endeffekt dieses Komponentendenken
in die Django-Welt
zu bringen, weil de facto die Django-Template-Welt
ist ja immer noch, wie sie vor 15 Jahren
mal irgendwann angefangen hat
und da zu überlegen, dass man Komponenten
bauen möchte, vor allem in so einer Kombination mit Tailwind,
die ja dann eher diese Utility-Based-Klasse,
also ein normales
Tailwind-Div hat noch 10, 15
Klassen,
so, das eskaliert ziemlich
hart. Ich finde es gut, aber
wie gesagt, es ist nicht schön
anzugucken und von daher die Sachen eher zu kapseln
und zu sagen, ich habe jetzt nicht, wie bei Bootstrap
zum Beispiel früher, ich habe hier
eine Button-Class und dann sieht dieser Button halt so aus, wenn ich
überschreiben muss, bin ich halt arm dran,
dann wird es schwierig,
sondern dass man wirklich die Sachen individuell
mit diesen Klassen halt definieren kann, ohne halt
die ganze CSS-Magie dahinter 100% verstehen
zu müssen und da
diese Komponenten in der Django-Welt
zu machen, klingt super interessant,
Das konnte man vorher auch schon mit Includes machen.
Ja, genau, mit Includes. Es gibt auch eine neue Version
von Includes irgendwie, die das so ein bisschen
zwischenspeichern können irgendwie auch.
Ja, auf jeden Fall, da gibt es Packages,
die explizit dafür da sind, um diese
Frontend-Learnings auch in die Django-Welt
zu bringen. Wir haben uns jetzt für Django-Components entschieden.
Das scheint auch okay gut zu
funktionieren. Habe auch von einem Freund gehört,
der das ausprobiert hat, der da meinte, dass er damit
gut und der eigentlich auch sehr viel und gerne
im Frontend gemacht hat, jetzt aber aus
besagten Effizienzgründen halt gewechselt ist.
Und
Genau, das ist auf jeden Fall eine interessante Sache. Also wer sich damit beschäftigt und halt ein Frontend bauen möchte, für das man sich in 2024 nicht schämen muss, dann glaube ich ist diese HTML, Excel, Python, JS und dann irgendwas an diesen Komponentenlibraries, die sich gerade, die emergieren gerade alle.
also ich glaube, da gibt es noch nicht so diesen de facto Standard,
aber wenn man sich da so ein bisschen reinliest, da findet man relativ,
also nicht viel, viel, aber da gibt es auf jeden Fall schon Inhalte
und da kann man sich am Ende vielleicht auch irgendwas aussuchen,
das ist alles nicht so kompliziert, was einem gefällt.
Habt ihr mal schon mal herumgespielt mit dem HTMX-Ding für Mobile?
Also in einem Hypermedia-Systems-Buch, das letzte Kapitel,
wo es dann darum geht, dass man das Ganze auch in Mobile einsetzen kann
oder soll oder so.
Als so
Ja, so eine Art von XML-Endpunkt, die dann irgendwie gerendert werden kann
von, ich glaube React war es tatsächlich, React Native
und dann Apps hat auf dem Telefon, die dann diese einzelnen Komponenten
halt mitziehen können, einfach von deinem normalen Endpunkt.
Klingwild.
Ich habe es noch nicht
angeguckt.
Also ich habe auch für
so mobile finde ich
eigentlich so die Webviews oder wie
heißen die noch? Progressive Web Apps.
Genau.
Ist eigentlich eine sehr schicke Geschichte.
Geht auf iOS auch deutlich mehr inzwischen als
früher. Wurden die nicht irgendwie gebannt?
Nee.
Apple hat da gedroht, aber das ist dann nicht
passiert.
Glücklicherweise.
hat doch ein bisschen zu viel
Gegenwind gegeben.
Und ich denke,
dass man vieles, was halt man
irgendwie vielleicht mit nativen
Apps früher gemacht hat, auch mit
Progressive Web Apps
hinbekommt.
Ansonsten sind halt die
Mobile-Geschichten halt immer so eine komplizierte
Geschichte, wenn man da wirklich eigene...
Ich meine, für manche Sachen, wenn man
eh dafür ein Team hat und genug
Geld, dann...
Ich würde das tatsächlich irgendwie mal ausprobieren.
für diesen Ansatz ganz cool,
Hikar Media für
Mobile
auszuprobieren. Das klingt irgendwie super.
Das ist derselbe Standard da
und derselbe Prinzip.
Das ist eigentlich, glaube ich, eine ganz gute Überleitung zu dem
nächsten Minithema, nämlich
Lightning Talks. Wer es nicht kennt,
die Lightning Talks,
das ist bei den Django-Cons zumindest, ich war noch
auf keiner anderen Konferenz, aber ich glaube, es gibt
auch andere Konferenzen, die ist jetzt am Ende des Tages
fünf bis zehn Leute
einen hart getimten
fünf Minuten Maximalfortrag halten
können über irgendein Thema. Das heißt, die Vorbereitung
ist sehr gering bis nicht
vorhanden bei den Leuten.
Der coolste Vortrag, den ich
gehört habe, war Fuck it.
Zwei Minuten.
Die Idee dahinter ist einfach,
genau das, was du gerade gesagt hast. Ey, ich habe dann im Buch
dieses Kapitel gelesen, finde ich total spannend,
habe ich noch nicht ausprobiert, wollte ich mal mitgeben.
Oder, was ich vorhin gemacht habe, ey, es gibt Jungle Components,
wer sich dafür interessiert,
schau ich das mal an. Und da ist
normalerweise die Informationsdichte
sehr hoch und auch die Unterhaltungsdichte
sehr hoch, weil natürlich Leute auch dann einfach mal einen Spaßvortrag
machen oder irgendwas
Absurdes aus ihrem Alltag erzählen.
Ja, oder kannst du deine Ukulele mitbringen.
Ja, genau.
Und ich finde, wir haben jetzt das auch
bei uns intern,
in meiner Firma,
bei den
internen Barcamps so gemacht, dass wir
auch einen expliziten Lightning-Talk-Block haben,
weil viel von so Content-
Teilen und Wissensmanagement
scheitert daran, dass die Leute sich wirklich aufraffen müssen,
Sachen vorzubereiten, Sachen zu recherchieren.
Es gibt gewisse Ansprüche, die Leute an sich haben.
Es gibt vielleicht Erwartungshaltungen,
die existieren mögen oder auch nicht existieren
mögen. Aber so ein Lightning Talk gibt es
das halt nicht. Du stellst dich da hin oder in dem Fall
jetzt in der Post-Corona
neuen Moderne, du sitzt dann hinter, vor deiner
Webcam und teilst dann halt kurz
deinen Browser oder deine zwei Slides und
sagst, Leute, das habe ich gesehen, das habe ich gelernt
voll gut oder auch
voll kacke. Und
und das ist ein echt cooles Format,
den man auch, wie gesagt, gut, glaube ich,
in Firmen oder auf Meetups auch sehr gut,
wir haben mal einmal vor ein paar Monaten,
ich glaube im Februar diesen Jahres,
haben wir eine komplette Lightning Talk Session gemacht
beim Django Meetup Köln hier
und das ist echt ein cooles Format,
was viele von den Problemen löst,
die man sonst so hat,
wenn man Content teilen möchte.
Ja, ich finde auch,
also gerade in jedem Format,
also das irgendwie für Konferenzen oder Barcamp
oder was man auch immer hat,
zusammenarbeitet, ist dieses Lightning Camp, äh, Lightning Camp, sag ich mal,
das Lightning Talk-Format echt cool geeignet, um so ein bisschen
lockere Atmosphäre reinzubringen. Entweder am Ende eines Tages oder am Anfang von diesem,
wir teilen uns in irgendwelche Sessions auf, so kurze Slots, selbst wenn es nur eine Viertelstunde ist,
zwei Minuten oder eine halbe oder sowas, um so ein bisschen mit den Leuten so reinzukommen.
Das ist echt schön. Ich glaube auch außerhalb vom Coding, ehrlicherweise. Man muss halt, glaube ich, immer noch so
auffassen, dass man halt wirklich hart guckt, dass die nicht überschritten werden, weil einige Leute
dann ihr Co-Referat halten, das dann doch ein bisschen länger wird.
Ja, das
nervt die meisten immer, glaube ich.
Und eine andere super Sache
ist halt auch einfach mal ein Gefühl zu bekommen, ob man
selber mal einen Vortrag halten möchte. Eingangs habe ich ja gesagt,
das war echt eine richtig coole Erfahrung
und ich habe auf der letzten
Konferenz in Edinburgh
habe ich auch einfach mal einen Lightning Talk gehalten,
um mal zu sehen, um mal so
den Fuß ins Wasser zu halten, wie ist das
überhaupt?
Über was?
Um den Fuß ins Wasser zu halten.
Ach so, den Fuß ins Wasser zu halten.
Nein.
Nur Füße und Wasser.
Angeln mit den Fäden.
Das war die Frage.
Ich habe tatsächlich
keine Ahnung. Ich habe dieses Jahr
einen über meinen Django Migration Zero
Package gehalten.
Ich beantworte meine Frage aber mit diesem Jahr,
weil ich es beim letzten Mal vergessen habe.
Ist ganz cool. Es ist ein Pattern, das hat sich
2018 jemand ausgedacht. Wer schon mal
mit Django Migrations gearbeitet hat
und länger auf einem Projekt war, weiß, da sammeln sich
ziemlich viele Migrations nach kürzester Zeit an.
diese Migrations, wenn man
die volle Kontrolle über seine Datenbank
hat, also zum Beispiel beim Package hat man das nicht, weil
das installiert sich irgendjemand und dann macht irgendwer was
damit, das ist außerhalb der
Macht des Creators, aber in so einer klassischen
Applikation, die man baut, hat man eigentlich die volle
Kontrolle über die Datenbanken, dann ist
irgendwann es auf dem letzten
Product-Release-System angekommen und die Migrationen haben de facto
eigentlich keinen Wert mehr, außer vielleicht einen historischen,
der aber auch sehr relativ zu sehen ist,
weil abgesehen von natürlich Kasten-Daten-Migration
die ganzen Sachen auch im Git irgendwie, die ganzen
Model-Änderungen hinterlegt sind.
Viele Migrationen führen dazu, dass die Tests langsamer laufen, dass die Testdatenbank aufgebaut wird, weil oft ist es ja so, dass es ja nicht ist, man fügt immer was hinzu, sondern da kommt was hinzu, dann kommt wieder was weg, dann habe ich was geändert, dann habe ich zum 18. Mal irgendwas geändert und Django bietet dafür eine Möglichkeit an, das nennt sich Squash Migrations, um das aufzuräumen.
Das Problem ist, das kann sehr, sehr
schlecht mit Circular Imports umgehen.
Also sprich,
ich habe einen User und der hat ein Projekt und
das Projekt hat, keine Ahnung,
Kommentare und die Kommentare haben wir den User.
Das heißt, man muss dann, wenn man
das macht, diese Migration
sehr stark auseinanderziehen.
Wie man das auch bei Circular Imports machen würde,
das ist ja generell das Python-Thema.
Und das ist sehr, sehr mühsam,
was dazu führt.
Und wie das halt dann immer so ist
mit Sachen, die mühsam sind.
Leute machen sie nicht. Umso einfacher Sachen sind,
umso schneller und umso besser werden sie getan.
Es gibt einen Pattern, das nennt sich Migration Zero
und das hat sich jemand
bei Medium 2018 ausgedacht,
da sitzt er schon eine Weile und die Idee ist halt einfach
auf Deutsch gesagt, du löscht halt
einfach alles, haust alles weg, was du hast und lässt
einfach Django initial
neue Migrationen erstellen.
Das klappt auch für große Projekte
sehr gut. Also ich hatte das beim richtig großen Projekt
mit großem Entwicklungsteam,
fünf, sechs Jahre Laufzeit, hatte ich einen
Mini-Konflikt, der aber auch so offensichtlich war, dass ich ihn sofort lösen konnte. Also es war wirklich gar kein Problem.
Und da habe ich halt dann dieses Package gebaut, das dieses
Pattern implementiert und das ist im Endeffekt ein zweistufiges Ding. Einmal habe ich einen Helfer
gebaut, der halt einem Verein quasi durch alle Apps geht, die Sachen aufräumt, weil das tatsächlich auch,
wenn man das öfter macht, ist es, je nachdem wie viele Apps man hat, ist es auch Arbeit, auch wenn es doof klingt.
Und das Zweite ist ein Skript, das in die Pipeline geht, weil Django hat ja alle
Migrationen, werden in der Datenbank in so einem Log,
in so einer Historientabelle hinterlegt, da quasi
noch die Änderungen anpasst.
Das heißt, du kannst es einfach in die Pipeline hängen,
du hast den Django-Admin in Switch, du sagst, ja,
jetzt habe ich Migration gelöscht, jetzt bitte beim nächsten
Deployment, bereite bitte
die Datenbank auf, um diesen Prozess zu
streamlinen. Und das ist ein Thema,
das verkauft sich sehr schwer, weil
es ist halt, wie wahrscheinlich es auch
der geneigte Zuhörer gemerkt hat,
relativ tief und auch nur
so ein Edge-Case. Eigentlich sollte man es tun, aber so richtig Lust hat
da keiner drauf.
Ich weiß, du hast mir schon mal drüber gefallen, dass wir irgendwie dann Migrations erinnert haben,
und Bum, oh, Datenbank nicht.
Genau, und ja, aus dem Grund
fand ich das eigentlich für ein Lightning Talk ein ganz cooles
Thema, weil so war das den Leuten so, Leute, wenn ihr das
Problem habt, guckt euch das an, das gibt's.
Ich habe dabei, als ich das
Package gemacht habe, auch direkt noch eine zweite Sache gelernt.
Es ist super, wenn man einen
coolen Namen für sein Package hat, man sollte aber vorher gucken,
ob der vielleicht schon belegt ist, weil
es gibt nämlich ein
Django Zero Migration
und Migration Zero ohne Django,
glaube ich, bin ich ganz sicher.
Du hast es dann Zero Migration 2 genannt.
Django Migration Zero gab es tatsächlich
noch nicht, aber es ist
natürlich trotzdem allein schon wegen SEO extrem
blöd, wenn halt dann Leute ständig aus falschem
Package kommen, weil das andere halt schon seit 2014
da rumsitzt mit einem Commit
Genau, von daher, wenn ihr mal ein Package
erstellt, dann checkt vorher die Namen ab, das hilft
Genau
Jochen sollte das Package unbedingt mal benutzen
Ich habe ja gestern nochmal über die Schultern geguckt, als du Django Cast
migriert hast und irgendwie wie viele Migrations
da dann von weg herangekommen sind, das waren ja hunderte
Ich habe mir das auch überlegt, dass ich das überall
wegschmeißen möchte. Aber dann denke ich mir immer,
das sollte ich vielleicht dann machen, wenn sich an der Datenbank
nicht mehr so viel an der Datenbank aus der Datenbank zieht.
Genau, aber ich werde das auf jeden Fall
tun. Ich würde mich freuen, wenn du mein Package
ausprobieren würdest. Ja, kann ich mal
probieren, genau. Aber das
Problem ist auch bei mir, es ist halt
eine blöde Art Library und ich werde Leuten...
Bei der Library geht es eh nicht.
Da musst du ja mit Squashen
arbeiten.
Du weißt ja nicht, in welchem Stand
quasi die letzte Person
dein Package,
die Person dein Package nutzen.
Ja, vielleicht werde ich
bei irgendeiner Major-Version...
Release-Update und wer weiß,
wie viele Leute außer Jochen sein Jochen-Paket sind.
Ja, ich kann sagen, dass es nicht so viele sind.
Das ist schon richtig.
Schieße ich nur in meinen Fuß
und nicht in den Fuß von noch 100 anderen Leuten.
Das kann ich vertreten.
Das Risiko von Open Source.
Man kann ja dann downgraden.
Datenbank brennt.
Sorry, downgrade einfach.
Ja, ja, ja, ja
aber ja, das ist ein Problem
ich meine, das ist auch so ein Problem wie bei so Projekten
wie zum Beispiel Wagtail
da hat sich halt, es ist ja auch schon recht alt
und das ist halt auch, das verwendet man ja auch
als Library und da hat sich so viel Zeug
angesammelt, dass halt das mit dem Testen
also, wenn man jetzt quasi
und mein Paket hängt zum Beispiel auch von Wagtail ab
deshalb muss ich für alle Tests
und so immer so Wege drumherum finden, dass ich
auf jeden Fall beim Testen nicht die Migration
laufen lassen muss
weil sonst werden die Tests irre langsam.
Also machst du reuse DB.
Und dann musst du halt dafür ganz hart sorgen, dass alle
Verschiebungen wieder aufgeräumt werden.
Minus minus no migrations, genau. Aber dann
gibt es halt dann so Fälle, wo
muss man es doch haben. Zum Beispiel
wenn man dann halt per Tox die ganzen
unterschiedlichen Versionen durchgeht, dann muss man natürlich
wenn man jetzt, dann kann man nicht die gleiche Datenbank
verwenden. Dann muss man halt schon die Datenbank wieder wegschmeißen.
Es ist
es geht, aber es ist halt, es ist hacklich.
Ja.
Ja, also in der Pipeline.
Ja, du hattest ja gerade mich schon wegen Edinburgh gefragt, was ich sehr interessant fand jetzt in Vigo. In Edinburgh gab es von mehreren Leuten die, ich glaube auch berechtigte Kritik, dass die Themenauswahl zwischen, meistens kann man das ja grob in Community Talks oder Community Talks und Tech Talks mit vielleicht Meta Talks, die irgendwie dazwischen sitzen, aufteilen und in Edinburgh war es relativ stark auf der Community Seite.
also Leute, die über Community-Erfahrungen berichtet haben, wo Parallelen gezogen werden zwischen anderen Arten von Communities.
Meine Erfahrung, wie ich das erste Mal zu Django contributed habe, solche Geschichten.
Das ist in Edinburgh von mehreren Leuten die Kritik, dass das halt relativ viel war.
Und das ist mir positiv aufgefallen, dass ich fand, dass die Mischung aus den Community-Talks und aus den Tech-Talks und aus den Meta-Talks richtig gut war.
und ich
sehr happy war mit
der Themauswahl. Ich meine, wie gesagt, es sind halt immer
eine große Menge auch von Leuten,
die das mit Absicht zum
ersten Mal machen, die
englisch nicht als Muttersprache haben und sowas.
Das ist natürlich immer Sachen...
Ich habe immer gehört, dass Spanien immer so ein bisschen anstrengender ist,
was so das angeht. Also für Englisch,
weil halt da Englisch nicht so verbreitet ist und viele Leute
halt dann nicht so...
Wir hatten auch, glaube ich, gar nicht so viele Spanier.
Ich glaube, eine Frau aus
aus Katalonien, was jetzt so ein bisschen
definitionsaristisch aus Spanien ist oder nicht.
Und ansonsten,
ja, vielleicht ein, zwei,
aber wie gesagt, generell
fand ich das diesmal
gut. Es war sehr angenehm,
waren viele interessante Sachen dabei.
Da gab es zum Beispiel einen von Octopus Energy,
das ist einer von den großen Django-Playern, die auch
eigentlich immer so mit Platinum-Sponsor bei den Konferenzen
sind, über Layered Architecture bei Django.
Ich bin schon sehr gespannt, wenn das Video rauskommt.
Das war sehr, also bei YouTube werden
die ja alle veröffentlicht, das war sehr
sehr viel Information da drin.
Ich habe mir nur ein ganz, ganz
paar wenige Fotos gemacht und ich bin sehr
gespannt, mir das Ganze noch mal in Ruhe
zu Hause anzuhören.
Genau, wie geht die Background Workers, die Sache von
Carlton Gibson, es gab coole Meta-Talks.
Also das
fand ich von der Auswahl her, bin ich
da mit vielen schlauen Gedanken nach Hause
gegangen. Und
was ich auch sehr interessant
fand bezüglich des Community Talks, direkt die
allererste Keynote ging um
Django Girls. Das ist eine
Vereinigung, eine Non-Profit, glaube ich, inzwischen auch,
die dafür da ist,
explizit Frauen
ans Programmieren ranzuführen, weil es ja immer noch
so ist, dass halt die IT-Branche immer noch
hart in Männerhand ist und das soll einfach
vor allem die
Mädels so ein bisschen ermutigen,
dass sie das können. Also nicht irgendwie,
ich glaube, da ist gar nicht so groß der Faktor, dass du da rausgehst.
Also das ist immer so ein Wochenende-Workshop.
Genau.
Und der U-Python ist auch, glaube ich, ein ganzer Workshop
für Tango Girls.
hier. Und ich war, als das mal hier
in Köln war, 2015 glaube ich,
war ich auch mal da Coach
und das war eine sehr interessante Erfahrung,
hat echt Spaß gemacht
und war
auch interessant, wie, weil die
Mädels, da habe ich alle komplett noch nie
irgendwas programmiert haben, also wirklich,
die waren komplett bei Null, die drei,
die in meiner Gruppe waren und wie die da auch unterschiedlich
rangegangen sind, das war wirklich auch für mich,
also im Sinne von, man hat ja auch immer wieder mal mit neuen
Leuten zu tun, wenn mal jemand Neues anfängt, wenn man mal
Werkstudenten betreut oder sowas. Echt interessant zu sehen,
dieses Coaching zu machen.
Und wie gesagt, das ist halt vor zehn Jahren,
das war jetzt Jubiläum, in Berlin gegründet worden, was ich
auch ganz cool finde.
Wenn jemand jemand kennt,
eine Frau kennt,
die potenziell sowas Interesse hat,
die werden immer wieder mal hier und da
angeboten, diese Workshops.
Und das ist, glaube ich, echt cool.
So für einen ersten
Fuß ins Wasser halten mal wieder.
und
die Idee dabei ist, dass die halt im Endeffekt ihre erste
Django-Seite erstellen und auch
irgendwo hin deployen und der Fokus ist
eher darauf, wie du schon gesagt hast, positive
Bestärkung, denn
pädagogisch wertvoll.
Tutorial ist auch relativ gut
und relativ komplett.
Wenn man überhaupt in Django ansteigen will,
hätten wir es früher sagen müssen, die Leute, die jetzt noch drin sind,
sind wahrscheinlich eher schon tiefer auch in Django,
aber ja, das kann man weiter verraten.
Ja, aber das sind dann auch die
motivierten. Bei denen lohnt sich das dann.
Ja, vielleicht tragen das dann ihre eigene
Communitys weiter auf. Du kannst einfach
in der Linksammlung noch hinzufügen, da freuen die sich.
Ja, auf jeden Fall.
Ich habe das auch tatsächlich an die Neulinge
bei uns mit Dango, auch einmal Dango Girls.
Also er ist natürlich offizielles Tutorial,
ist nicht schlecht, aber Dango Girls auch so schönes
schnelles Einstiegsding.
Ich erinnere mich gerade, ich war jetzt zu langsam, um da
einzu... Ich habe mich dann irgendwann
kurzer Nacht daran erinnert, es gab auch
jetzt irgendein...
Muss ich auch nachgucken, welcher das war.
Podcast-Episode Django Chat mit
einer von Octopus
Energy und die
erzählte da auch irgendwie, ja,
dass sie halt
auf so ein
Problem gestoßen hat, dass sie eigentlich
nicht wollen, dass in Templates irgendwie
Datenbank-Queries passieren oder so.
Und das ist auch etwas, was mir inzwischen
halt, ich habe ja versucht, so ein bisschen Performance-Optimierung
zu machen, auch bei den
Django-Cast-Dingen,
was ich baue, und
das ist mir auch ganz böse auf die Füße. Also
eigentlich, da dachte ich auch so,
oh ja, eigentlich möchte man nicht,
also wenn man in Templates Datenbank-Queries
macht, ganz blöde Idee, die sind dann
so weit gegangen zu sagen, sie benutzen
so eine Art Class-Based Views,
wo sie halt verhindern, also sie nehmen nicht die
Modelle, sondern sie machen irgendwie da so
Data-Class-mäßig irgendwie
Read-Only-Kopien von den Dingern,
sodass wenn du da irgendwo was versuchst
aus der Datenbank zu holen, dass das
halt einfach nicht geht.
Das kann ich gut verstehen.
das ist eine, also du willst eigentlich
wenn du zum Beispiel deine Daten
die Anzahl der Datenbankquerys in der Kontrolle behalten willst
willst du halt irgendeinen Punkt haben, wo du sagst
also hier, da sind alle Queries
und ich mache nirgendwo anders welche, weil
das ist so schwer
zu containen, wenn man
wenn da irgendwas passieren kann, dass das
halt ganz blöde Performance-
Implikationen hat. Und wo man dann quasi
durch das Frontend auch Angriffe machen kann oder was?
Ne, Angriffe, also es ist einfach
irgendwie, das ist halt
unheimlich
macht Dinge halt deutlich langsamer
und man weiß gar nicht so, warum
irgendwie.
Und ja,
also zum Beispiel...
Datenbank-Queries sind immer super langsam.
Ja, aber warum muss das, also wenn man die
eh machen muss, warum dann nicht im Template?
Also man muss ja eh drauf warten.
Naja, wenn man die halt an einer Stelle macht,
dann ist es halt auch nicht so schlimm.
Das weiß ich nicht so genau, das ist ein Gefühl.
Das habe ich noch nicht wirklich gemessen, aber ich habe auch das Gefühl,
dass wenn man die
Datenbank-Reels sehr verstreut macht,
dass das halt besonders schlecht ist auch.
Warum das genau ist, weiß ich nicht.
Was meinst du, was an verschiedenen
Stellen im Code meint er halt?
Oder an verschiedenen Orten des
Frameworks, glaube ich. Meinst du?
Ja, also wenn ich jetzt zum Beispiel gucke von
es kommt ein Request rein, ja, dann
passieren ja Dinge, Dinge, Dinge, Dinge, Dinge.
Auch erstaunlich viele, das weiß ich jetzt,
weil ich es halt so ein bisschen geproffelt habe.
Bei mir sind es halt von, also
wenn man jetzt einen Blog nimmt und da die
List-Page und dann halt nur so fünf Artikel
oder sonst irgendwas. Also aus diesem Listview
dann macht das halt so
110.000 Funktionsaufrufe oder sowas.
Was eine Menge ist. Ich dachte so, wow,
shit, warum ist das so viel?
Das ist ganz schön viel. Und mein Ding wäre jetzt,
wenn jetzt so alle tausend
Funktionsaufrufe kommt,
dann kommt irgendwie die Datenbank-Query. Das ist schlecht.
Also so war es quasi vorher
irgendwie implizit, weil
die Datenbank-Query ist halt da passiert, wo es
halt
aufgetreten ist. Und das war
und einfach nur dadurch, dass ich
und halt blockiert und dann muss man auf die Datenbank warten sondern auch dieses Ganze irgendwie ja man ist da in diesem Bereich wo dann Dinge die Jungle gebaut werden
oder ich weiß es nicht so genau, also das scheint alles nicht so
richtig kostenlos zu sein, sondern
das heißt, wann irgendwas geladen wird an der Stelle
und warst du irgendwie vorbereitet oder teardown
oder so hin und her, kostet dann unheimlich
viel, oder? Ja, also
ja, das allein, dass man da halt
irgendwie viele Objekte erzeugt und dann
ja, und wenn das halt
an einer Stelle ist, dann passiert das halt einmal
und wenn das halt verteilt ist, dann macht es das
irgendwie nochmal langsamer.
Und ja, ich versuche immer noch momentan gerade rauszukriegen,
woran liegt das eigentlich, dass da so viele Funktionsaufrufe
passieren, weil das ist einfach zu viel.
Kann man nicht eventuell,
also meine Idealvorstellung wäre natürlich,
dass ich irgendwann sozusagen
nur noch eine Datenbankquery mache oder so,
in der ich alle Informationen aus der Datenbank hole.
Geht das nicht vielleicht?
Ja, Tim, wie groß hättest du, wenn das
in RAM passt?
Ja, das ist alles gar kein Problem.
aber kann ich
so eine Query formulieren und wenn ich
jetzt die Daten aus dieser Query habe, kann ich die so transformieren
dass ich daraus wieder Django-Objekte machen kann
das ist halt so, das mache ich jetzt auch schon
also ich benutze nicht mehr
irgendwie einfach so, ich mache
aus
ich benutze nicht quasi
den ORM um halt Django-Modelle, sondern ich
ziehe die Daten halt in
einer Form, das ist auch sowas
wenn man cachen will, dann muss man das ja auch irgendwie
zum Beispiel als Sticked haben
dass man halt auch irgendwie serialisieren kann
Wenn du Django-Objekte hast, die kannst du nicht
also es gibt viele Dinge an Django-Objekten, die kannst du
nicht serialisieren.
Du kannst es auch nicht cachen, weil
Furry-Sets kannst du nicht gut cachen. Geht nicht.
Aber wenn du jetzt das in eine
Dict-Geschichte
überführt hast, wie im Prinzip
JSON serialisierbar ist, dann kannst du
halt auch das, was du aus der Datenbank kriegst, einfach
nehmen, irgendwie auf eine Platte schreiben oder so und sage
okay, die nächsten fünf Minuten einfach das Pfeil
nehmen und nicht mehr die Datenbank fragen. Oder
irgendwo in den Hauptspeicher oder in Redis oder sonst irgendwo hin.
und dann kannst du das halt cachen.
Aber das, genau.
Und aus den Dingern
Jungle-Modelle zu bauen, ist jetzt gar nicht so schlimm.
Da dachte ich auch so, das ist vielleicht schlimm.
Nö, ist gar nicht so schlimm. Ziemlich leicht.
Und ja, genau.
Also ja, ich mache momentan so ein bisschen Performance-Optimierungsgeschichten.
Ja.
Ja, aber wenn Performance auch dazu führt,
dass du weniger Rechenleistung aufwenden musst, ist das ja sogar
Green Engineering.
Ja, ja.
Da gab es auch Vorträge dazu
110.000 Funktionsaufrufe für ein Webseitenrendering
ist nicht so richtig cool, ehrlich gesagt
das ist eher so mehr so braun
Aber Walter, ich habe gerade
deinen Einstiegspunkt vergessen
der mich daran erinnert hat, aber es war super interessant
bei diesem Dango Girls Vortrag gab es auch
so eine
ja so Success Stories einfach
von Mädels, die das halt teilgenommen haben
und die jetzt halt irgendwo einen coolen Job haben
oder irgendwie eine coole Erfahrung haben oder irgendwo
und Jochen unterhalten sich über die Programmiersprache Python
wo man dann irgendwie bis nachts um 12 irgendwie irgendwelche Marketing-One-Pattern zusammenlötet.
Nein, du hast völlig recht.
Ich glaube, das ist einer der Jobs, die von Hause aus sehr dafür geeignet sind,
dass man das remote machen kann und es relativ kompatibel ist zur Vereinbarkeit von Familie und Beruf.
Das ist eine echte Arbeit von zu Hause aus.
Eine Menge Geld verdienen.
Hier ist in die Halle angewogen.
Ich glaube, eine gesellschaftliche Transformation wäre sowas wie Vereinbarkeit.
eine der Hauptdinge.
Das fällt mir auch immer wieder auf.
Ja, das ist halt,
wenn irgendjemand den ganzen Tag irgendwo hinfahren muss
und dann mit Kinderbetreuung ist das schon schwer.
Ja, also ich meine auch
in den letzten Jahren
mit Kinderbetreuung, es passiert immer so viel
Zeugs, wo man dann,
das wäre übel gewesen, wenn ich
jetzt hätte in einem Büro sitzen müssen.
Oder hinfahren jeden Tag.
Du kannst auch nicht glücklich wegfahren.
Oder Schichtdienst einfach die ganze Nacht.
Ja, ganz übel.
Ja gut, aber es gibt Leute, die kriegen das trotzdem irgendwie hin.
Ja, das ist sehr beeindruckend.
Ja.
Ja, du wolltest jetzt über Party reden,
auch wenn wir gerade über Kinderkriegen reden.
Ja.
Für manche Leute ein Thema. Nach der Party kommt der Kater
und...
Nein, tatsächlich, bei den Dungercons
gibt es immer eine Party und
ich fand das ein ganz interessantes Thema,
weil in Edinburgh
war es so, dass man,
wenn man sich die Tickets kauft, musste man
ein Opt-in machen, ob man auf die Party
und Jochen unterhalten sich über die Programmiersprache Python
auf einmal alle nicht dahin gehen konnten, weil
sich eingeladen zur Praxis. Ach so.
Und weil einfach, weil halt
das Heck hier nicht gesetzt wurde und das war halt irgendwie
einfach so ein bisschen die Realität
zu Theorie. In der Theorie ist es kein Problem,
in der Praxis, naja, so ist es halt.
Gehört eigentlich dazu. Und ich persönlich
finde nämlich die Party eigentlich immer eine sehr schöne
Art nochmal mit Leuten, die man halt
vielleicht noch auf der Stage gesehen hat an den Tagen.
Die sind ja auch meistens eher am Ende.
Das ist mir in den Google-Python auch aufgefallen, da gibt es auch mehrere
Partys, wo man sich extra registrieren muss.
und ich finde das eine sehr schöne Gelegenheit, nochmal in einem etwas lockeren, weniger
ernsten Umfeld mit den Leuten, ich meine, viele Leute haben da irgendwie
da noch mit den Leuten reden zu können, einfach nochmal
mit Leuten connecten zu können, zum Beispiel in Porto, also jetzt vor zwei Jahren, die Party war
glaube ich eine der besten Partys, also die war super, das war echt gut organisiert,
richtig schöne Location, bestes Wetter, alles draußen
und da bin ich dann einfach in eine Runde von Leuten reingestolpert und dann bin ich
nachher mit einem im Gespräch hängen geblieben und nachher
irgendwann meinte er, weißt du
echt, wer ich bin? Ich sage, keine Ahnung, ich bin
Präsident hier von Django Software.
Oh, ups, sorry.
Da kannte ich halt noch nicht so viele
Leute in dem Umfeld. Und es ist halt einfach,
das würde halt so, ich meine, das kann passieren,
wenn man so auf der Konferenz rumläuft,
aber man ist da schon immer relativ getaktet
mit. Dann gibt es
eine Verlosung und dann ist der nächste Vortrag
und dann muss man sich vielleicht selber auf irgendwas vorbereiten.
Dann will irgendwie die eigene Crew
irgendwas.
und Konferenz-Experiments.
Da kann man auch eine eigene Folge zu machen, glaube ich.
Und das fand ich tatsächlich,
ich finde das einen sehr wichtigen Punkt, weil es ja immer
dann auch von, ne, auch dann so, naja,
sieh du uns auf, nö. Aber ich finde, es ist schon
sehr, sehr schöne
Atmosphäre und Möglichkeit
mit Leuten nochmal so zu socialisen,
auch mal Leute ein bisschen persönlicher vielleicht auch
kennenzulernen und
genau, also fand das wirklich schön und
jetzt bei diesem Mal, das war so
ein bisschen doppelt unglücklich,
und Jochen unterhalten sich über die Programmiersprache Python
wie gesagt in Porto glaube ich waren
bis eins oder zwei
ich glaube in Kopenhagen davor
war auch relativ lang, solange wie Leute
mehr da waren oder solange die Organisatoren halt Lust
hatten, so dass das nicht abschließen
zu wollen und
ja, das fand ich tatsächlich ein bisschen schade
wird bestimmt seine Gründe gehabt haben
ich will mich da jetzt gar nicht irgendwie
ich habe mich dazu beigetragen, ich will da nicht rummosern
ich persönlich fand es nur schade, weil
wie gesagt, ich meine es ist ein sehr schöner Ort
finde und ich meine auch da habe ich mich
mit Leuten unterhalten, mit denen ich
mehr oder weniger im gleichen Raum saß für drei Tage und halt vorher noch nicht gesehen habe,
hatten interessante Gespräche und genau, das finde ich immer
einen schönen Ort und kann da auch nur eine Lanze dafür brechen.
Also ich würde auch sagen, Socializing bei diesen Konferenzen ist mit so der Hauptgrund, warum man da
ich finde das ja auch, gestern war ja wieder bei DDF auch immer super, dass man danach noch was essen geht,
weil da auch immer der Hauptteil des Spaßes ist, also nichts gegen die ganz tollen Vorträge, die alle tollen Menschen machen,
mir halt auch bestimmt bei der Dango-Con, wo ich dagegen meine, der auch da hinfährt und so, aber das Socializing ist
und das ist ein großer Teil, dass man so Leute kennenlernt, also dass diese Experience, die man von anderen Menschen mitbekommt, die was ähnliches machen, vielleicht ein bisschen anders als man selber und sich darüber austauschen, das ist schon super.
Also manchmal kann man auch selber mal ganz viel reden, das machen einige Leute gerne, aber auch manchmal zuhören ist auch super und das ist irgendwie was Gutes.
Ich kann das auch sehr nachvollziehen. Ich finde das auch mit den wichtigeren Teilen.
Manchmal ist man ja auch im Gang so ein bisschen.
Und weil du gerade sagtest, das fand ich interessant,
deine Art und Weise war wahrscheinlich sehr strukturiert
und sehr organisiert, möglichst viel
von dem Content mitzubekommen.
Von der
Europe Python kenne ich es zum Beispiel so, die ist ja lang.
Und wenn man da halt die ganze Woche da ist, dann sind es ja sieben Tage.
Also zwei Tage Workshop, drei Tage
Vorträge, zwei Tage irgendwas anderes.
Da tut es immer ganz gut, wenn man sie ein
oder zwei Tage nicht ganz so vollpackt,
weil man so ein bisschen sich so
fließen lässt.
Weil dann kommt man mehr mit Leuten ins Gespräch, die auch
und so weiter.
zu ein oder zwei Vorträgen,
was manche an Kinderbetreuung liegt oder sowas, die man da
netterweise hinbringen kann. Oder halt nur sogar
Notschuldensprünge gab es, glaube ich, auch Menschen, die halt wirklich
nur da hingegangen sind, um mit den Leuten an Sachen zu arbeiten.
Aber das ist so witzig,
weil diese, das ist so ein bisschen, ich weiß nicht, ob es eine
Kulturfrage ist, aber so diese Art und Weise ändert
sich je nach Lebensphase oder wo du
gerade selber bist, total. Und das
ist, glaube ich, auch eine der Herausforderungen für so Konferenzen,
für die unterschiedlichen Ziele,
die die Leute so mitbringen, irgendwie gut
ausgestattet zu sein. Und mich würde dieses
Django-Conding auf jeden Fall auch mal reinziehen, ehrlicherweise.
und die Programmiersprache Python.
und ja, Dublin, ja, es ist einfach eine tolle Stadt in Irland, das ist eh, wenn ich noch Bier trinken dürfe, wäre ganz toll, überall wunderschöne Sachen.
Du musst halt Whisky trinken.
Ja, am Shannon entlang ist es immer toll, da gibt es tolle Sachen, ich meine, es ist halt sehr moderne Hilfestadt auch, ne?
Naja, gut, das sind die meistens alle irgendwo, bis auf hier, Jochen.
Tja.
Ja.
Aber das waren jetzt aber drei Tage quasi, ne?
Genau, das war eine 3-Tage-Konferenz.
Da gab es einen Konferenztrack und dazwischen gab es immer wieder mal in einem anderen Raum die Workshops.
Ich habe die Workshops nicht teilgenommen.
Ich nehme irgendwie von diesen Workshops nicht so viel mit.
Ich war letztes Mal in Edinburgh bei den Sprints dabei.
Und man muss auch sagen, das ist kein Umfeld, wo ich wirklich produktiv arbeiten kann.
Dann sitzen da ganz viele Leute in einem Raum und es ist halt so ein gewisser Geräuschpegel.
Weiß ich nicht, jedem zweiten fehlt irgendwie Strom und dann hast du da kein Ladekabel.
und es ist
also es ist unruhig.
Interessant, also ich finde das mit dem Workshop sich total
anders, also weil, vielleicht bist du schon
viel weiter als ich in dem Punkt, aber
die Dinge, die ich da so mitgenommen habe,
da 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, ich gehe halt auch ganz
gerne auf die Konferenzen, nehme
mir die Stichpunkte mit und
und sortiere dann quasi danach nochmal so ein bisschen aus,
was weichere ich ab, also es existiert irgendwo.
Zum Beispiel diese Sache mit der Architektur, das finde ich super spannend.
Ich müsste auch nochmal, also ich gehe da auch nochmal ins Gespräch mit ihr
und gucke mal, ob wir sie vielleicht mal zum Django Meetup Köln oder sowas einladen können oder sowas,
weil das ist halt ein Thema, das halt für mich super spannend ist
und wo ich auch noch definitiv zu wenig weiß.
Und das ist, so gehe ich dann damit um.
Also das ist jetzt nicht vielleicht gleich deine Länge in der Workshop.
Also die Workshop, die ich hatte, waren halt mindestens einmal einen halben Tag,
also vier Stunden oder so.
Ich bin da richtig tief in die Themen
reingekommen, hab mich da richtig reingehackt, hab da auch wirklich
was gemacht und hab dann auch teilweise noch wirklich nachgearbeitet
und die Dinge wirklich umgesetzt
und benutzt. Also da sind die eher kürzer,
also ich glaube so ein bis zwei Stunden,
glaube ich, ich bin nicht ganz sicher.
Letztes oder letztes Mal hab ich mal welche mitgemacht,
aber wie gesagt, irgendwie die Atmosphäre ist nicht so ganz
mein. Ich konnte zum Beispiel auch konzentriert arbeiten,
weil es da ruhig war. 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 rumzusteigen.
Ja, genau.
auch cool, glaube ich. Auf jeden Fall, auf jeden Fall.
Also wir haben ja auch beim Django
Meetup in Köln jetzt im Januar hatten
wir Sarah A. und Thibaut,
also die sind beide Django Board Members,
ganz frisch geworden, hatten wir
eingeladen, sind netterweise
vorbeigekommen, da haben wir dann auch einen Open Source Sprint
gemacht. Der schon am Mittag war, wo ich leider erst so
spät konnte. Und das
war auch echt cool.
Also es war eine coole Erfahrung. Jeder hat da so ein bisschen an dem gearbeitet,
wo er drauf Lust hatte.
Es sind mehrere Tickets auch erstellt worden
und
oder mehreren
Pull-Defers erstellt worden.
Und danach hat man noch so ein bisschen Diskussionen
so Future of Django, was auch
super interessant war, weil man halt wirklich mal zwei Broadminers am Start hat
und dann wirklich mit denen so ins 1-2-1
gehen kann. Aber wirklich, ich bin da gar nicht
dagegen oder so. Ich sage nur, das ist halt nicht so
mein Arbeitsunfall. Ich finde,
wirklich programmieren...
Also kategorisch, ja. Es ist nicht nur so zufällig gewesen, sondern du denkst,
du brauchst eher deine Ruhe. Ja, definitiv.
Aber was ich dann interessant finde, ist, dass du
zwischendurch, also ich weiß nicht, ob sich das geändert hat,
sagtest, dass du im Büro total
und das sogar zu Hause vorzieht.
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,
also nur einen Tag die Woche im Büro war,
dann hast du halt ständig irgendjemanden,
mit dem du dich über die letzte Woche austauschen musst.
Das lenkt dann schon sehr ab.
Aber wenn du drei Tage da bist,
dann hast du halt deine Nasen alle gesehen
und dann streckt sich das so ein bisschen über die drei Tage
und dann ist es eher das,
wenn man eh mal gerade eine Pause braucht,
wenn man kurz für die Tür geht oder so,
und
Ja, wir könnten noch Pics machen.
Das klingt, glaube ich, ganz gut.
Und dann, das war eigentlich auch schon
eine runde Sache.
Ja, dann bin ich ja mal gespannt,
was für Pics
wollt ihr denn nehmen.
Soll ich anfangen?
Du hast einen von mir geklaut.
Ich habe mich
in letzter Zeit nochmal so ein bisschen,
also es gibt da auch sehr schön,
das kann ich vielleicht dazu sagen, einen 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
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
für solche, also ich benutze es dann halt auch
für solche Dinge wie
alle, ich habe jetzt sogar eine Funktion
tatsächlich für Django Cast 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 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 ein System-Prompt zu
von wegen, ja, habe ich bei der Dokumentation
irgendwas vergessen oder kann man das
irgendwie, gibt es 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,
dass man halt auch wieder irgendwie auslesen kann und
analysieren kann. Und dann kann man totaler Zeit deine Templates
verwenden, die man halt auch dann hintereinander
pipen kann und dann kann man auch das Default-Template
überschreiben werden 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.
Ich habe zum Beispiel so einen,
den nenne ich dann den Senior,
dann gibt der mir immer schnippische Antworten,
wie ich das von Jochen immer kenne.
Es funktioniert super, es macht sehr viel Spaß.
Und dann sagt der mir so, warum hast du das denn nicht selber
rausgefunden? Hättest du auch die Anleitung.
Das ist toll und es macht so ein bisschen Spaß beim Arbeiten,
wenn man dann Fragen stellt und jemand, der dann so
antwortet. Das ist sehr lustig.
Sehr gut.
Genau.
Ja, also das Ding, ups,
das wäre dann mein Pick, genau.
Ja,
Ronny?
Boah,
so ganz spontan
fallen mir nicht
mehr Sachen ein.
Du kennst etwa die Praxis nicht von dem Pick
der Woche des Monats hier bei uns im Podcast?
Also ich kenne das doch, aber mir fällt gerade
nichts wirklich ein, was ich nicht gerade schon irgendwie
in einer Art und Weise erwähnt habe.
Hast du einen interessanten Talk gesehen?
Wenn dir ein Talk zum Beispiel bei der DjangoCon
super gefallen hat, dann können die Leute
ihn jetzt noch nicht sehen, aber
irgendwie sich schon mal darauf freuen, dass es
später auf YouTube gibt oder so.
Also wie gesagt, der Talk über die
Layered Architect über Django,
ich weiß nicht genau,
wie er hieß, der war auf jeden Fall sehr spannend
und auch einen Talk,
wenn man sich für Django interessiert und auch
die Idee bezüglich
großer Applikationen
und wie lässt man eine Django-Applikation wachsen,
weil ich bin schon davon überzeugt, dass man auch
große Applikationen damit bauen kann.
Nicht nur zwingend dieses kleine
Blog-Ding, womit es mal angefangen hat.
Da gibt es einen Talk, Scaling Django
to 500 Apps.
Das ist auch Kraken,
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
Kapsel, das haben ja viele Frameworks
und die haben da eine Idee,
naja, in ganzer Hinsicht 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
Naming-Konvention, um im Endeffekt zu sagen,
ich habe immer noch eine
Domäne, die sich um mein Projekt
oder mein Accounting oder mein weiß der Geier
was kümmert, mein Produkt, aber da drin
das ist so groß geworden, ich möchte das weiter strukturieren.
Und das
finde ich super spannend, das ist gerade auch eine Sache, über die ich
sehr aktiv nachdenke, wie ich das in meinen
Projekt, in dem ich aktuell arbeite, reinbringen kann.
Weil ich jetzt
zum Beispiel in meinem Projekt, wir haben
da so ein bisschen, also manche
Apps sind einfach riesig geworden, wo man sagen muss, die müssen
aufgeteilt werden. Und mit diesem Sub-App-Gedanken
bin ich heute einfach nur in diesem
Structure-View, also wo man quasi sieht, welche Klassen
gibt es in meiner Datei. Einfach mal mit
einem Blick sind mir und meinem Kollegen
wirklich einfach so, okay, das ist ein
Kontext, also das ist so eine Sub-App,
das ist super schnell,
wie so Sachen reingehen, wo man auch sagt, okay, das gehört hier echt gar nicht rein,
das muss eigentlich komplett woanders hin.
einfach nur mit einem Blick und diesem Gedanken, dass es
dieses Sub-App-Pattern gibt.
Dann auch bei ein paar Sachen gesagt, okay, das ist definitiv
kein Sub-App, das muss einfach, das ist ein Standalone,
das kann man gut rausziehen.
Das finde ich auf jeden Fall einen sehr interessanten Vortrag, den ich
jedem ans Herz legen kann, der sich
für sowas interessiert.
Sub-Apps habe ich ja auch in letzter Woche in irgendeinem Projekt eingebaut,
aber ohne das Pattern dazu.
Aber ich bin eigentlich eher, gut,
vielleicht bin ich da auch irgendwie falsch abgebogen,
aber ich bin eigentlich eher so auf dem,
ich mache gar keine Django-Apps mehr, weil
also immer, wenn ich
Wie sonst?
Naja, einfach ganz stinknormal mit Python
Bordmitteln Dinge modularisieren.
Modular, ja.
Weil das Problem bei den Apps ist halt
einmal, ja,
das 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, das was ich eigentlich
am
fiesesten finde, ist, dass man halt,
man kann halt Sachen schlecht refactoren,
so von einer App zum Beispiel in eine andere,
und man kann die Migration nicht umziehen.
Aber so Modelle, genau. Wäre so ein Punkt, wo ich sage,
wenn es irgendwo Modelle gibt,
ist für mich immer bisher so eine App.
Ja, aber was machst du dann, wenn du mal
das eine Modell in eine andere App ziehen willst?
Das ist mühsam, das habe ich schon gemacht. Es geht, aber es ist mühsam.
Also weil,
ja. Also musst du halt mit
RAW SQL und
Daten halt. Ja, klar, du kannst natürlich,
es geht schon, aber es ist halt nicht einfach, man
verschiebt es. Da kann man auch alles kaputt machen.
Ja, genau.
Wenn man es halt alles in einer App hat,
sozusagen, dann kann man es einfach umziehen.
Das ist eine interessante Idee, habe ich nicht drüber nachgedacht.
Dass wir diese Modellis für das
Myco-Diskussionieren machen.
Ich habe meistens dann zum Beispiel Models,
also wenn es größer wird, dann habe ich halt ein
Models-Verzeichnis.
Alle Models in einer Datei.
Nee, genau, das eben nicht mehr, weil das wird dann halt riesig.
Also wenn Models
irgendwie größer wird als tausend Zeilen oder so,
dann würde ich denken, gut, dann wahrscheinlich sollte man es mal ein bisschen aufteilen.
Und ja,
dann kann man die ja auch so gruppieren und dann
hat man noch eine Init-Py, in der man dann halt
irgendwie festlegt, welche überhaupt exportiert werden sollen, weil viele Dinge braucht man gar nicht nach außen reichen, sondern die sind ja rein intern.
Das ist interessant, da habe ich noch nicht drüber nachgedacht,
so ein API zu sehen.
Ja, das finde ich auch. Also ich mache halt unterverzeichnis, wo nur bestimmte Sachen rauskommen, die anderen Sachen
implizit intern.
Das ist interessant, da habe ich heute noch drüber nachgedacht, aber
dass das ein Benefit ist, habe ich
nicht drauf gekommen. Das ist interessant.
Ja, cool. Und dein Pick?
Mein Pick, ich habe natürlich wieder von Jens geklaut, der das in unsere Gruppe geschrieben hat, ist MonkeyType.
Das ist von Instagram entwickelt worden, wenn ich das richtig verstanden habe.
Und das baut dir Type Annotations.
Das heißt, du gehst einfach hin und hast irgendeine Python-Funktion oder sowas und sagst dann Command-Seite MonkeyType
und dann nimmt der halt die File oder das Ding und schreibt da die Annotations dran.
Das ist gar nicht so schlecht.
Das funktioniert besser, als man vielleicht denkt.
und wenn man halt gerade nicht so weiß,
warum 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.
Man entdeckt manchmal sogar auch Bugs,
das stimmt aber eigentlich gar nicht oder so.
Ja, man erwartet andere Sachen.
Oder oh Mist, dann kommt auf einmal der Delinther oder MyPy
und sagt halt so, ne Moment, der Destroider wäre jetzt gar nicht das.
Das ist schon ganz gut.
Interessant.
Ja, gut, dann würde ich sagen,
Haben wir für heute die Episode?
Dann herzlichen Dank, dass du wieder da warst, Freund.
Ja, vielen Dank.
Dann machen wir es gleich noch unter uns weiter, würde ich sagen.
Herzlichen Dank fürs Zuhören.
Bleibt uns gebogen, wo immer ihr auch seid.
Danke, Jochen.
Und Feedback an hallo.at,
peißenpodcast.de, Feedback, Anregungen, Kommentare,
Lob, Kritik und so weiter.
Was ihr alles möchtet. Bis bald.
Bis dann. Tschüss.