Transcript: Live von der DjangoCon Europe 2025 in Dublin - Tag 1
Full episode transcript. Timestamps refer to the audio playback.
Ja, hallo, herzlich willkommen beim Python-Podcast, Episode 63.
Heute gibt es eine Sonderausgabe.
Wir sind nämlich auf der JungleCon in Dublin.
Ja, und wir sind...
Hallo, Jocken.
Hallo, Dominik. Johannes, Dominik.
Johannes.
Hallo.
Hi, Sarah.
Und?
Hallo.
Ja, wir haben einen Gast, Sarah.
Ja, wir wollten euch ein bisschen was erzählen, was hier so passiert
und das vielleicht auch die nächsten Tage so machen.
Das wissen wir aber noch nicht ganz genau.
Wir wollen nichts mehr versprechen.
Wir haben letztens schon so ein paar Sachen versprochen,
die ein bisschen spät dran waren beim Release.
Das machen wir diesmal nicht.
Sondern wir erzählen euch einfach ein bisschen, wie es hier so ist.
Lassen den News-Tag diesmal weg.
Und gucken, was so passiert. Genau.
Ja, ähm...
Wie gefällt es euch denn hier in Dublin?
Also, wir sind ja gestern angekommen
und wir sind gleich von...
Am Taxistand hat uns die freundliche Dame darauf hingewiesen,
dass heute sehr gutes Wetter wäre.
Weil es nicht regnet.
Und das hat sich dann hier im Hotel...
Waren sie auch alle glücklich, dass es nicht regnet?
Leider hat es dann am Nachmittag doch noch
angefangen zu regnen.
Aber ich hab gehört, es war Average.
Ja, aber es war schon so,
dass man sieht dann so Regenschlieren
so im Wind vorbeiziehen.
Ja, und als es ins Restaurant reingeregnet hat,
haben sie auch alle gesagt, ach, das ist noch durch.
Also seid froh, wenn ihr gerade im Trocknen seid.
Und es hat auch auf den Tisch getropft ein bisschen von oben.
Alles durchschnittlich.
Alles irisches Wetter.
So war unser erster Eindruck gestern.
Ja, wir sind nämlich auch alle im gleichen Flugzeug gekommen.
Das fand ich auch sehr lustig.
Dass da irgendwie so...
Wie ein Drittel von den Passagieren
irgendwie wegen der Django-Con
darüber geflogen ist.
Ja, aber vielleicht wollen wir auch ein bisschen was
zur Konferenz erzählen.
Und tatsächlich, ich glaube, Sarah, du könntest vielleicht anfangen,
weil du hast auch die Keynote gehalten am Anfang.
Ja.
Ja, klar.
Ich habe eine Keynote gemacht
und ich habe
gesprochen über...
Wie man bei Django mitmachen kann.
Genau.
So auf meine Meinung.
Django braucht mehr
PR-Reviews, weil
wir haben so viele
Pull-Requests und nicht so viele Leute,
die PR-Reviews machen.
Und ich glaube,
es ist...
Nicht so viele Leute denken,
das ist ein gutes Ding zu machen.
Das ist natürlich auch total schwierig,
weil man traut sich das erstmal gar nicht zu.
Warum sollte ich jetzt unbedingt
das große Django-Reviewen machen?
Aber das, was du gesagt hast,
macht doch einfach mit. Das ist super.
Und man kann das auf jeden Fall gebrauchen.
Wir sollten vielleicht noch sagen, dass
Sarah der aktuelle Django-Fellow ist
und dass sie deshalb durchaus
Autorität hat, darüber zu sprechen,
wie man da mitmacht.
Der Django-Fellow ist von der
Django Software Foundation
eine Position, wo eine
Person bezahlt wird, um an Django
zu arbeiten. Vollzeit.
Das heißt, wie lange machst du das schon, Sarah?
Seit ein Jahr.
Seit einem Jahr schon.
Das heißt, du hast wirklich genügend Erfahrung,
zu sagen,
was gebraucht wird und was nicht gebraucht wird.
Ja.
Wir haben ja alle schon
in so Umgebungen gearbeitet, wo man
Pull-Requests macht und wo dann Review gemacht wird
und ich hatte immer das Gefühl,
dass Review so ein bisschen
die Schranke ist, dass da
ein Gatekeeper steht
und sagt, du darfst oder du darfst nicht.
Aber es gibt ja noch nach dem Pull-Request
die Mergers. Genau, das ist
der erste Sicherheitsmechanismus,
der mir gut gefallen hat, dass man
nicht die
alleinige Verantwortung hat.
Aber du hast ja schon so ins Plenum gesagt,
tut das bitte.
Genau.
Ich hoffe, dass es gibt mehr
als ein Mann,
dass ein Pull-Request
Review machen und wir können
viele Leute
ihre Meinung
sprechen, dass
ja, diese Feature
gefällt mir oder nicht und
Es gibt ja so verschiedene
Seiten, von denen man das sehen kann.
Jeder hat ja so einen eigenen Stil und da gefällt
anderen Leuten, fällt natürlich andere Dinge
fallen denen auf. Ja, klar.
Ja, aber
gibt es irgendeine
Erkenntnis darüber, warum
das vielleicht so wenig, warum Leute das nicht so gerne
machen oder so, oder kann man das eventuell irgendwie
leicht, könnte man die Motivation leicht verbessern
oder so, ich weiß es nicht so genau. Sarah sagt, es dauert zu lang.
Klar, es gibt,
es ist schwer zu sagen,
warum man das
machen sollte, weil
ja,
es gibt
kein Geld und
Das siehst du mir jetzt auch nicht.
Und dann, du bist nicht
die
Author von
dieser Code.
Der Ruhm und Ehre geht an den Menschen, der diesen Code
mitgeschrieben hat.
Ich weiß nicht,
warum es gibt
ein paar Leute, das
zu viel Zeit
schon, aber
ob
man ein paar
Stunden pro
Monat
kann PR
oder pro Woche
PR-Reviews
machen, dann es kann
so viel für
Django
machen. Die Django-Community
profitiert auf jeden Fall massiv
von diesem Ding. Ich habe es mir
tatsächlich,
überlegt, ob ich nicht mal mir sowas angucken will
und hatte mich auch gefragt, ob ich mich denn für gut
genug halte, das Django-Review
zu machen. Das war tatsächlich auch so eine Hürde.
Auf jeden Fall.
Auf jeden Fall. Es gibt einen Endpunkt, also
code.django-project.com,
wo man dann halt die offenen
Pull-Requesting kann und filtern kann nach Dingen,
die einen interessieren und da kann man sich dann
mit auseinandersetzen und
sich einen raussuchen, wo man halt tatsächlich schauen
kann. Es gibt auch eine Anleitung,
also ein Contributors-Guide, wo man halt ein bisschen
sieht, auf was man alles achten soll,
ich glaube, die Sachen, die man da sieht, sind schon
durch verschiedene Prozesse gegangen, also
ihr nennt das Triage, glaube ich.
Und in diesem Triage
wird halt geguckt, gibt es schon Tests,
gibt es schon Dokumentation und
ist das denn alles einigermaßen ordentlich?
Und was ich auch spannend herausfordernd
fand, war, dass es halt verschiedene Teile
von Django gibt, die alle auch einen unterschiedlichen
Stil haben, also wahrscheinlich weil unterschiedliche Leute
daran geschrieben haben, das so herauszufinden,
dass das schon, ja, interessant ist,
da so ein bisschen dran zu
trainieren.
Es gibt halt so Teile, wo
die Innereien vom ORM oder so,
da glaube ich, viele Leute würden da zurückschrecken
und denken so, oh, oh.
Da sind vielleicht auch nicht ganz so viele PRs
offen.
Genau, das wäre auch interessant. Gibt es da irgendwie Tendenzen,
wo halt die meisten Pull-Requests
offen sind, oder ist das
komplett über die Code-Basis verteilt?
Es gibt viel für die
ORM, es ist ein
sehr...
Es ist ein großer Teil.
Ja, genau, und es ist
ein...
Ja, ein Kernbaustein.
Genau, und es gibt ein paar Leute,
das können diese Reviews
sehr gut machen. Es gibt
einen Mann, der heißt Simon
Charette, und
er macht
die besten Reviews
und viele
seit...
Es wird wie jedes
Tag ein bisschen
für Django machen.
Aber
ich weiß nicht, es gibt...
ein paar
PRs für vielleicht
jedes
Teil von Django.
Das heißt, ihr findet auf jeden Fall einen
Teil, wo ihr noch mitmachen könnt.
Das ist auf jeden Fall eine gute Sache, ja.
Und es ist auch eine super wichtige Sache, diese Code-Reviews.
Also in allen Teams, in denen ich
bisher gearbeitet habe, waren Code-Reviews
einfach super wichtig, um
das Team zusammenzuhalten.
Gibt es die lieber, oder bekommst du die lieber?
Das ist eine sehr schwierige Frage,
weil es sehr auf den Kontext ankommt.
In den Teams, in denen ich gearbeitet habe,
habe ich beides gleich gerne gemacht.
Weil es einfach ein Teil...
Es war so ein Geben und Nehmen.
Einerseits
habe ich natürlich, wenn du ein PR stellst,
erwartest du ja, gerade in einem kommerziellen
Kontext, dass du nicht vier Wochen warten musst.
Und das heißt,
du möchtest, dass die Kollegen das schnell machen.
Und umgekehrt verpflichtet es dich dann
natürlich auch, darauf zu reagieren,
wenn jemand anders einen PR stellt.
Das ist in Open Source vielleicht noch ein bisschen anders
als im globalen Kontext.
Im professionellen Kontext hast du halt auch
diese politische Ebene dazwischen, dass man
seinen Kollegen immer dann direkt mergt,
weil man mag die ja und möchte keinen Ärger haben.
Oder man ist nicht allzu kritisch.
Engere Teams, also wenn du mit zehn Leuten zusammenarbeitest,
ist das was anderes, als wenn du im Open Source
mit tausend Leuten zusammenarbeitest.
Und was man bei einer Firma oder so auch oft machen kann,
ist, dass man einfach erst mergt und dann reviewt.
Das ist jetzt bei Django vielleicht eher schlecht.
Ja, weil wenn
seine Kollegen etwas
kaputt machen, dann
spätestens... Dann holt man sie sich und
sagt ihnen, du, du, du.
Das darfst du aber nicht. Mach
das nicht nochmal. Ja, aber wenn man
Tests gehabt hätte, ja. Ja, klar. Also in dem Sinne
ist das Review hier ein viel
größeres Quality-Gate. Es ist ein viel größeres
es darf nur Sachen rein,
die auch reingehören.
Aber umso wichtiger ist es ja, dass tatsächlich Leute
kommen und das dann auch tun.
Und ich glaube auch als Reviewer kann man
was lernen. Also auch wie man Reviews macht.
Absolut. Und es ist ein sehr wichtiger
Skill. Und ich glaube
aber, dass es nicht, also
für mich ein Kernpunkt, den ich
mir bei deinem Vortrag auch gedacht habe, ist, wenn ich
einen PR stelle, dann habe ich hinterher eine Zahl
an meinem GitHub-Account dranstehen.
Wenn ich Review mache, dann
stecke ich da vielleicht genauso viele Stunden rein.
Aber das ist unsichtbar.
Und schon allein dieses
Number-Goes-Up-Spiel, was man
da spielen kann, ist ja schon ein Motivator.
Das ist ja mehr Gamification für deinen
Review-Account. Ja, ich weiß, dass das bei mir
funktioniert und ich weiß, dass das bei vielen anderen
Leuten funktioniert. Und es ist ja auch was
wert. Es ist ja auch was wert. Das hast du auch
in deinem Vortrag gesagt. Wenn jemand
bevor sich die Leute für Summer of Code vorbereiten,
machen sie schnell noch fünf PRs und sagen dann,
haha, ich habe da was reingekriegt.
Aber niemand würde auf die Idee kommen, fünf Reviews
zu machen, weil da kann man nicht draufzeigen und sagen,
ich habe Review gemacht.
Und ich glaube, das ist einer von den
Motivatoren, die da einfach fehlt. Aber es ist
auch sowas Unsichtbares.
Ein PR ist eine Sache und
die macht man und dann ist die
dafür immer. Und diese Review ist sowas,
ich habe dir ein paar Kommentare
gesagt. Und die werden
ja auch unter Umständen gar nicht Teil des Repositories,
sondern Teil des Trucks.
Das Truck wird dann irgendwann
irgendwas anderes migriert und dann
schicken sie dann oder so. Also es ist einfach nicht sichtbar.
Es ist nicht sichtbar, dass jemand Review gemacht hat.
Es ist nicht, es gibt keinen
Punkt, den man dafür kriegt, kein Sternchen.
Ruhm und Ehre der Community.
Ja, natürlich, es verbessert das, aber das
reicht offenbar nicht. Denkst du,
es gibt etwas, das Django machen
kann für das?
Ja, es wurde ja vorhin auch schon vorgeschlagen,
dass man einfach das sichtbar macht.
Dass man sichtbar macht, wer Reviews
macht. Auch bei der
ersten schon. Du hast auch gesagt,
es gibt eine Gruppe von Leuten, die das
Review-Bit haben oder wie auch immer,
die dann halt da aufgehört sind.
Aber das ist für mich jetzt als
Angestellten oder
als Freelancer, ich habe da nicht genügend Zeit,
um in diese Gruppe vorzustoßen.
Das heißt für mich als
Einzelperson wäre es wichtig, dass
wenn ich so ein Review mache,
dass es dann auch sofort irgendwo steht.
Ich will Instant Gratification haben.
Und ich glaube,
wenn man das sichtbar machen würde, dass es das gibt,
und dass man dafür Punkte
bekommt, egal welcher Art die sind,
dann würde das schon deutlich mehr Leute
anziehen. Ich weiß aber nicht, ob das
Pull-Request-Review-Leadership-Board
vielleicht
umgekehrt
muss man natürlich auch aufpassen,
dass das nicht so Leute anzieht, die dann sagen, ja, ja, ja.
Ja, genau.
Shai
Berger hat mir gesagt,
dass es gab
ein Ding
für die Co-Team. Es gibt
kein Co-Team jetzt, aber
vorher
man muss fünf
PR-Reviews machen und dann
ihre
PR kann ein Review
haben.
Und das hat
eigentlich funktioniert,
Shai hat gesagt.
Vielleicht das ist auch eine Idee,
dass wir können das wieder machen oder
etwas ähnlich.
Keine Ahnung.
Es gab ja noch die nächste Idee dann, dass halt viele
von den erfolgreich
reviewten Pull-Requests dann irgendwie
kurz vor Mergen liegen bleiben, weil auch da ja
niemand da ist, der das hauptberuflich
macht. Und es halt nur sehr wenige
Merger gibt. Und wir hatten
eben die Diskussion draußen
nochmal. Also ich glaube, Karin Gibson hat gesagt,
hey, was hältst du denn davon,
wenn es mehr Leute gibt, die mergen? Und wir haben uns
draußen unterhalten und gesagt, ja,
Django ist deswegen toll seit 20 Jahren,
weil es total stabil ist und der
Code total super ist und die Dokumentation total
toll ist. Und ja, dann
kam halt wieder dieses Thema auf,
wir merchen das. Und das wäre natürlich
auf einmal,
muss man sehr aufpassen, wer das dann ist.
Weil sonst hast du halt Sachen drin, die dann
vielleicht nicht so passen. Und wie viele
von diesen Mergers gibt es? Keine Ahnung.
Was hältst du davon? Also du hast
eben gesagt, du weißt es nicht genau.
Also es gibt jetzt
vier Mergers.
Es gibt
die Fellows, ich und Natalia.
Ich glaube, es gibt
Marisch Felisiak und
Cloud Poros.
Aber
die meisten
Purikers sind
bei den Fellows.
Vielleicht
Marisch
macht schon
ein bisschen mehr.
Aber
ich weiß nicht, weil es gibt
die
Entscheidung,
dass es ist
äh,
wirklich gut.
Und es ist auch die Entscheidung,
dass, ähm,
ob etwas
falsch gemacht oder etwas
nicht so gut ist, dass
du kannst das
besser machen.
Und du glaubst, dass, okay,
vielleicht dieser
PR-Author
geht weg,
weil so viele Leute
bleiben nicht.
Dann, ja,
ich verstehe
die Code gut genug, dass
ich glaube, ich kann das
besser machen oder, ähm,
und das, keine Ahnung,
wie viele Leute, ähm,
würde das auch
fühlen, weil es ist
für mich, ich fühle, das ist
echte Arbeit und
vielleicht das braucht,
ja, man sollte
Geld verdienen.
Ja, so, keine Ahnung.
Ähm,
aber wir können versuchen.
Das ist so eine Probe im Merch.
Ich hab das jetzt gemerkt.
Fandet ihr das auch okay?
Ja, es ist auf jeden Fall
ein schwieriges Problem und, ähm,
das ist wieder so ein, wir haben da ja auch gestern
drüber gesprochen, ja, die, die technischen Probleme
sind ja oft relativ einfach,
also da kommen wir alle klar damit,
aber dann die organisatorischen und die Menschen
und die sozialen und die psychologischen und dann
da ist es
oft schwieriger als die, als
der reine Code.
Und da gab es auch noch,
den nächsten interessanten Vorschlag
und zwar, dass man halt die LNMs zur Hilfe nimmt,
um bestimmte Stufen da vorzubereiten.
Ähm, ich
finde die Idee gar nicht schlecht,
ehrlicherweise, weil ich glaube, wenn man sich so ein bisschen Arbeit
macht mit so Agents, die
dann customized sind für
Pull-Requests oder sowas, dann kommt man da
relativ weit mit, also auch mit dem Reviewen
von diesen Pull-Requests.
Ähm, ja, aber was...
Naja, das kann natürlich auch so ein Katz-und-Maus-Spiel
werden dann, weil es wird dann
möglicherweise, also du hast dann halt,
LNMs, die generieren PRs und dann
andere LNMs, die, ähm,
quasi, die weisen die dann ab und dann
wird, kann man auf beiden Seiten aufrüsten,
aber irgendwie hilft das dann auch.
Ja, vielleicht kommt ja dann tatsächlich ein ordentlicher Pull-Request bei raus.
Also das ist ja eigentlich das, was du willst.
Von wem der dann kommt, ist ja dann fast wurscht.
Ist auch egal, genau, wenn es stimmen würde hinterher, ja,
dann wäre es auch ein bisschen egal. Ja, ich weiß es nicht,
vielleicht muss man es einfach ausprobieren, keine Ahnung.
Ja.
Vielleicht das, kleiner Übergang von dem
Thema von Sarah, weil es gab noch so ein Workshop,
wie man Agents macht, das war auch gar nicht,
nicht uninteressant.
Es war nicht ganz so viel
Neues zu dem, was wir eh schon so machen,
aber es ist schon spannend,
wie man sowas,
einen Agenten dazu bringt. Wie wurde denn da
Agents eigentlich definiert? Also meine Definition
vorweg wäre einfach so, LLM
in a Loop.
Ja, okay, genau.
Das war ziemlich genau das, was wir da
gemacht haben, also einen Loop bauen für
LNMs, die dann verschiedene Prozesse
durchgehen können und dann halt Funktionen aufrufen
und Scraphyper dann halt für einen
eine Beantwortung, eine Frage, einen mehrstufigen
Agentenprozess, um bestimmte Sachen
dann to buy sind zu können.
Was man halt auch für so ein Pull-Request machen könnte.
Könnte halt gucken, hey, sind die Docs drin
und so weiter, sind die denn da, hast du einen Verbesserungsvorschlag
für die Docs, gehst du zum nächsten Test, sind die Tests drin,
gehen die Tests durch, in welchem Kontext gehen die Tests, sind die Tests
negativ, ja, also sind die Sachen,
die zum Beispiel rausgeflogen sind, gehen die Tests
da jetzt auch kaputt und wie ist das
und wenn du was verbesserst, wenn du was fixt, hast du
einen Test geschrieben vorher, der zeigt, dass das kaputt ist und ist
der Test danach grün, solche Sachen. Und
das kann man, glaube ich, durchaus in so einem
mehrstufigen Agenten beibringen.
Aber auch das ist halt wieder Arbeit, ja.
Wieder dabei sind so, hey,
wir brauchen tatsächlich ja für
diese Open-Source-Geschichte so ein bisschen
mehr Funding. Und das ist auch die Frage, woher das
kommt. Also da gibt es so
verschiedene Gates, die wir ja kennen.
Ja, aber alle unsere Zuhörer werden ja jetzt
gleich losgehen und PRs reviewen
und auch an die
DSF spenden. Genau.
Wir den Spenden-Link
putzen wir auch, meinte ich. Oh ja, den sollte man da
auch.
Ja, ich habe tatsächlich
ab und zu mal so die CTOs
oder die ein bisschen anderes Level noch
versucht zu bequatschen für, hey, wir
benutzt noch die ganze Zeit so Open-Source-Software. Wie wäre es denn,
wenn ihr von dem Budget so ein bisschen wieder zurückgebt?
Und die meiste Antwort war so, ja, warum denn?
So, okay, ja,
weil ohne das würde es nicht funktionieren.
Und ich habe das Gefühl, dass man bei den
kapitalistischen Organisationen da so ein bisschen
auf wenig Gegenliebe stößt, aber
vielleicht bei den staatlichen irgendwie.
Zumindest jetzt, wenn
bestimmte Regionen entdecken, dass das
ganz gut ist, wenn man unabhängige Software
hat, die man auch nutzen kann.
Das ist vielleicht so ein bisschen die Idee.
Aber auch das wäre so eine Sache, ne? Gibt es da
bei Django jemanden, der da aktiv
Fundraising in diese Richtung macht?
Ja, Carlton. Carlton spricht schon lange davon,
dass er...
Klar, es gibt ein Team, es gibt
die Fundraising Working Group
und ich glaube,
sie haben
ein paar Ideen, dass
die Django Software Foundation
machen könnten.
Aber
es ist
nicht so lang
seit dieser Team
gegründet war, so
keine Ahnung, was
sie machen jetzt.
Aber hoffentlich
wir haben ein paar Sponsors
und jedes Jahr
ich glaube, Catherine
von der DSF
wird wieder
mit dieser Firma
sprechen und
sie möchten wieder
sponsoren.
Ja, aber es ist
ein schweres Thema,
aber
ich glaube, die Sponsoren, meistens sind das halt auch
Leute, die man dann auch persönlich gut kennt
und wo man halt eine Beziehung über ein paar
Jahre oder aufgebaut hat schon.
Was eigentlich ein bisschen schade ist,
weil es nicht so diesen Public-Gedanken gibt.
Ja, aber im Großen und Ganzen steht ja
die Django Software von Deutschland ja schon vergleichsweise gut.
Die kann sich ja schon zwei Leute
leisten, die
also nicht Vollzeit, aber anderthalb Vollzeit
Personen und das ist ja für
eine Open-Source-Stiftung
riesig.
Ich wüsste nicht viele anderen Stiftungen
oder viele anderen Frameworks, die sich so
viel Betreuung leisten können.
Also der Erfolg ist ja schon
da, der muss nur noch größer werden.
Ja, es gibt natürlich so den anderen Weg,
so Laravel oder sowas, die dann
auf einzelne Leute mit viel Geld
gesetzt haben und das dann verkaufen, um
dann so einzelne
Microservices irgendwie da zu monetarisieren.
Aber ich finde es
ganz gut, dass wir das nicht so machen.
Ja, was gab es denn heute noch
so alles, was hatten wir denn noch?
Ja, ich glaube, wir haben noch ein paar Sachen, die wir noch nicht so gut haben.
Ja, ich glaube, wir haben noch ein paar Sachen, die wir noch nicht so gut haben.
Ja, ich glaube, wir haben noch ein paar Sachen, die wir noch nicht so gut haben.
Wir waren noch die ganze Zeit in der Mainhall
und haben euch die Talks angeguckt.
Das war auch sehr nett.
Ja, das mache ich auch seit einiger Zeit
sehr, sehr gern irgendwie.
Ja, das wurde da auch angesprochen mit
EdgeMix.
Ich habe eher sonst ein bisschen Probleme, das wirklich zu testen,
dass das alles funktioniert und dann muss man halt auch
so End-to-End-Tests machen.
Und Playwright funktioniert da echt super.
Also, genau.
Wir hatten kurz vorher die Frage,
macht denn Playwright über
PyTest dann einen Server auf, den es dann richtig
benutzen kann?
In den Beispielen jetzt, da haben sie das
so gemacht, aber dann
hat der, wie hieß er noch?
Jakob?
Er hat dann auch gesagt, ja, das hat er jetzt so
gezeigt, aber das macht er normalerweise nicht so und ich mache das
normalerweise auch nicht so, sondern
ich lasse einen Server speziell dafür
dann laufen, gegen den ich dann Playwright
laufen lasse.
Ich weiß nicht so genau.
Ich habe noch nicht so wirklich herausgefunden, wie man das am besten
macht. Aber
mein Weg ist gerade halt
einfach ein
Server,
aber mit einer speziellen Config laufen lassen,
gegen den ich dann
Playwright-Tests laufen lasse.
Dann kann man auch screenshotten, ob das Formular
ordentlich an der Stelle sitzt, wo man es erwartet in den verschiedenen
Ansichten.
Ja, das war eine sehr interessante Sache,
aber das war mehr so ein Denkanstoß,
fand ich. Ja, das war auch
kurz irgendwie so,
jetzt geht's los und dann so.
Danke, nächster Talk.
Aber es ist auf jeden Fall ein sehr interessantes
Thema und ja, also es ist schon faszinierend,
was da alles passiert.
Was hat man denn noch?
Wir hatten noch
diese unglaublich gute
War-Story von Tim Bell
über Datenbanken.
Jochen, da weißt du am meisten
Schmerz gehabt in dem Vortrag.
Du weißt ja von Datenbanken auch schon so viel.
Ja, aber das ist natürlich jetzt alles total lange her,
dass ich viel mit Datenbanken gemacht habe, aber
gerade die Namensgebung.
Dann haben wir eine
Schattenspalte irgendwie aufgemacht
und dann Schattentabellen und genau so
hatten wir das damals auch genannt.
Und ja, das ist immer das Problem,
wenn man halt irgendwie,
viele Änderungen gleichzeitig an der Datenbank
machen möchte, dann beeinträchtigt
sich das halt auch die
Leseperformance halt unter Umständen,
wenn halt die Tabellen gelockt werden oder
allein, wenn es schon langsamer wird, ist halt schon blöd.
Und wenn man jetzt halt irgendwie
viele Sachen ändern will, dann einmal
ja, lockt das die Datenbank, was halt doof ist.
Unter Umständen und
was halt auch doof ist, ist, dass es halt viel mehr
Platz braucht und man dann halt hier die
Tupels, also Postgres,
kopiert immer Tupels, ändert
die Datenbankzeilen nicht,
wirklich, sondern fügt dann
neue Zeilen hinzu und markiert die alte als
die kann jetzt weg. Und dann muss hinterher der
Staubsauger rüberfahren und die alle aufsaugen
und das dauert halt auch lange.
Und ja, das ist halt eine
komplizierte Geschichte. Und wenn man halt
viele Daten hat und so, dann
ja, dann muss man sich da
Strategien überlegen, wie man das hinkriegt, ohne den
Produktions-, Produktivbetrieb irgendwie kaputt zu machen.
Die Strategie, die dann gefahren wurde, war,
du baust die Tabelle einfach in neu
daneben und
replacest das dann? Ja, also oder
zuerst mal nimmst du eine neue Spalte
und hast einen Trigger, der quasi, wenn
sich was erst an der Originalspalte
ändert, die Änderungen halt überträgt
auf die neue Spalte
und
naja, dann irgendwann
renamest du die Spalten halt
atomar, was halt dann schnell geht
und
ja, dann hast du das halt sozusagen
erledigt, diese Migration, aber
ja, das ist halt, du kannst das Ganze dann
auch noch auf Tabellen machen, damit fangen sie jetzt gerade
an, wo man dann halt
eventuell sich das Vacuum sparen kann,
wo man die Tabellen, die man hinterher
umbenannt hat, einfach nur joggen kann.
Jetzt musst du einfach nochmal kurz das Überlass-Vacuum
eingehen, bitte, weil... Ja, also Postgres hat
halt so einen Auto-Vacuum-Prozess,
der halt dafür sorgt, dass halt
nicht die Platte dann irgendwann vollläuft oder die Datenbank
so langsam wird, weil das Working-Set zu groß wird und nicht mehr
in den Hauptspeicher passt. Und der muss halt
ab und zu laufen und die gelöschten
Zeilen halt irgendwie
tatsächlich wegwerfen. Also der Staubsauger?
Ja, genau. Und
genau, das ist halt,
an der Stelle ein Problem, wenn man halt viele Änderungen macht
und halt dann viele gelöschte Zeilen erzeugt.
Ja, und deswegen
vielleicht der Trick mit der, man macht das halt
in einer Tabelle
und dann schmeißt man die andere Tabelle einfach mal weg.
Und du hast gesagt, wenn eine Änderung reinkommt, die dann quasi
das, was man gerade eh ändern will, betrifft, dann muss man das
dann in beiden Spalten machen, oder?
Ja, also am Anfang,
bevor man die Spalten umbenennt,
hat man einen Trigger, der halt die Änderungen, die
in der Originalspalte passieren, halt überträgt
auf die neue. Und wenn
man das mit Tabellen macht, ist es ein Suchengrüne genauso.
Genau so. Und
ja.
Sarah, geht
gerade? Ja, vielen, vielen Dank.
Du musst noch Tschüss sagen, Sarah.
Du kannst ja nicht einfach reden, wir können ja einfach das Thema
unterbrechen, wenn Sarah gerade
das muss. Tschüss. Vielen Dank.
Danke, Sarah. Dankeschön. Vielen Dank.
Ciao.
Ja, und genau, das erinnert mich sehr stark
an das, was ich früher auch schon mal
gemacht hatte, da habe ich so einen Preisvergleich gearbeitet
und da war es auch so, dann kommen dann halt,
äh, neue Daten von irgendwie einem Shop
oder so, von Amazon kommt dann irgendwie eine Million neue Angebote
oder, ah, hat sich irgendwie der Preis geändert oder sonst
irgendwas und dann muss man halt das irgendwie ändern
und, äh, hat dann auch das Problem, dass wenn man
das halt so sukzessive
langsam, dann ist es, dauert es halt ewig,
äh, was schlecht ist, weil dann stimmen die Preise eine lange Zeit
nicht oder man macht es alles auf einmal, dann steht
das Produktionssystem, was halt auch schlecht ist, weil
dann, ja, dann verdient man
auch kein Geld mehr und dann muss man sich halt
irgendwie komische Dinge überlegen, bei denen man sich immer so
fragt, so, uh, ist das, was ich hier mache
eigentlich so noch in Übereinstimmung mit der Prophezeiung
oder habe ich mich auf irgendeinen dunklen
Pfad begeben, ohne Wiederkehr oder so
und, ja, genau das,
dieses, dieser Vibe war bei
diesem Tag auch spürbar.
Ja, er hat auch gesagt, dass es,
äh, also er hat das so ganz
freundlich und fröhlich vorgetragen und dann zwischendurch
hat er gesagt, ja, dieser Schritt, der hat
zwei Monate gedauert. Ja, genau, ja,
solche, ja, das ist...
Und außerdem haben wir 292 Schritte
manuell machen müssen für 18 Datenbanken
und das, äh, das war dann so ein zwischendurch
so ein kleiner Aufwacher, so ein
Jacki.
Ja, so ein...
Ah!
So viel, so viel manuelle Arbeit ist da drin.
Ja. Er hat dann ja auch von seiner
automatisierten Lösung erzählt.
Ja. Ähm, fand ich auch sehr
interessant. Würde ich
mich auch so nicht trauen, solche Sachen
auf Datenbanken laufen zu lassen, auch für Monate.
Ja. Ähm, ich musste auch noch mal mit ihm
sprechen und ihn fragen, wie sie
sicherstellen, dass während dieser Prozess läuft,
dass dann keine anderen Sachen
passieren. Ja. Weil
er am Anfang, äh, seines Vortrags
angedeutet hat, dass er sehr häufige
Deployments auf sehr viele verschiedene Systeme
Und ich könnte mir vorstellen, dass wenn da gerade die Schattentabelle befüllt wird, dass man derweil nicht viele andere Migrationen machen sollte. Und da sind ja auch Abhängigkeiten. Ich darf ja den Code erst ändern, wenn diese Schattentabelle fertig und eingesetzt ist. Erst dann darf ich ja den Django-Code anpassen.
Das heißt, es ist so ein mehrstufiger Prozess, wo man zuerst die Schattentabelle anlegt und dann befüllt und dann einsetzt und dann erst den Django-Code ändert.
Und wie sie diese Reihenfolge sicherstellen, wurde mir aus dem Vortrag nicht ersichtlich.
Die haben sicherlich Systeme und Schritte da eingeplant, aber das war so für mich nicht sichtbar.
Ja, danach haben wir uns den Data-Oriented Django-Vortrag angesehen von Adam Johnson, auch über Datenbanken.
Genau, von dem es auch schon zwei, äh, auf jeder Django-Code, vielleicht wird es eine Tradition, er macht auf jeder Django-Code.
Vorträge, das war der drei, genau. Das ist der dritte.
Der dritte Teil.
Und er hat auch gleichzeitig drei veröffentlichte Bücher.
Schon.
Ah, deswegen drei.
Genau.
Ja, und ja, das war wie immer super. Er hat halt einen Haufen Detail-Informationen darüber, wie, was man so an Indizes benutzen kann, wie man das in Django macht und so.
Genau, also im Endeffekt ging es darum, Datenbanken-Reads schneller zu machen und das Mittel der Wahl ist Indizes.
Und ich war überrascht, dass es da innerhalb von Django auch so viele Möglichkeiten gibt, das anzupassen.
Ich dachte, da muss man dann immer rohes SQL in seine Migration reinschreiben.
Ja, hatte ich auch gedacht.
Das wusste ich auch nicht.
Was ich auch schon gesehen habe.
Wie macht der das dann? Hat der ein Index-Field gemacht oder was, wo er dann da bestimmte Sachen reingebracht hat?
In der Meta-Klasse kannst du Indizes angeben, die für die Tabelle gelten sollen, die für das Modell gelten sollen.
Genau, und da hat er dann einen extra Fake gemacht, was er quasi beim Save mitschreibt oder sowas?
Nee.
Nein.
Nee, das war, bei Adam Johnson ging es nur darum, dass du Reads verbesserst, indem du Indizes anlegst, die dann von deinen Abfragen genutzt werden.
Da musste keine extra Felder dafür.
Da musste keine extra Felder dafür anlegen, sondern du sagst dem ORM nur, du möchtest auf diesem Modell einen Index haben, der bestimmte Eigenschaften hat und bestimmte Felder abdeckt.
Und die Reads benutzen die automatisch.
Also du überlässt es quasi der Datenbank dafür zu sorgen, dass die richtigen Indizes benutzt werden und musst dann nicht separat nochmal was machen.
Und das ist eigentlich relativ bequem.
Die überraschendste Sache in diesem Vortrag war allerdings, dass man die Default-Indizes austauschen kann.
Das heißt, auf Primary Keys, auf Foreign Keys und auf Unique Felder.
Gibt es immer einen Index, braucht die Datenbank, um überhaupt diese Constraints einhalten zu können.
Aber die kann man ersetzen.
Das heißt, wenn man weiß, dass man immer zu einer ID auch den Namen abruft, könnte man das in einen Index reintun und dann diese Abfragen nur über ID und Namen machen.
Dann würde der Zugriff nur auf den Index.
Ja, aber man muss dann auch hinterher so eine Methode wie Only auf dem Query-Set verwenden.
Genau, also man muss es dann auch so ein bisschen anpassen.
Aber diese Indizes anpassen, ich wusste nicht, dass das geht, dass man die Default-Indizes austauschen kann.
Ja, oder dass man halt noch zusätzliche Daten in den Index mit reinschreiben kann, die dann mit ausgelesen werden.
Ja, oder was ich auch nicht wusste war, dass man auf dem Query-Set sagen kann Explain.
Und dann auch noch sagen kann sowas wie, dem gibt man so ein Argument wie JSON gleich True oder so.
Und dann kriegt man JSON zurück und dann kann man dieses JSON nehmen und dann in PG Mustard reinschmeißen.
Was allerdings nicht Open Source ist.
Ne, stimmt, genau.
Und was ist PG Mustard?
Senf.
Ja, ja, Postgres, Sender Senf.
Das ist so ein Tool, das dir dabei hilft, deine Statements.
Diese Explains sind ein sehr komisches Format und die sind sehr schwer zu lesen.
Und PG Mustard macht eine Visualisierung erstmal davon, die zeigt dir, welche Tabellen an welchen Schritten wie verarbeitet wurden und was du besser machen könntest.
Und das ist, glaube ich, sehr nützlich.
Was ich mir dann tatsächlich noch gewünscht hätte, also wenn das ein Open Source Tool wäre, dass man das auf seiner Datenbank laufen lassen kann und quasi Explains sich rausfischen kann und dann direkt diese Indizes anlegen lassen kann.
Ach so, okay.
Weil der Schritt wäre ja...
Das automatisieren, ja.
Tatsächlich gar nicht so kompliziert.
Ja.
Dass der dir sagt, hier wäre ein Index nützlich, probier das mal und dann klickst du drauf und dann...
Man kann aber auch einmal die Datenbank selber kann man loggen lassen, zum Beispiel, wenn man sagt, also ab einem bestimmten Threshold von Zeit, ich weiß nicht mehr genau, wie es geht, ich weiß nur, das geht schon.
Also Queries, die länger brauchen als so, logge die mal alle weg, damit ich hinterher mir das angucken kann, ob da irgendwas drin ist, wo ich offensichtlich sehe, wie man das verbessern kann.
Oder man kann auch sowieso die Dinger mal samplen irgendwie, dass man halt...
Zumindest ein Teil der Queries halt irgendwo hat, dass man halt ein repräsentatives Sample der Queries, die so auf der Datenbank laufen, halt irgendwo mitloggt.
Ja.
Aber, ja, das müsste man dann auch irgendwie in diese...
Dass man dann einen Explains drauf macht, keine Ahnung, das müsste man dann noch wahrscheinlich selber machen, aber, ja.
Also da ist noch, da sind noch Lücken.
Ja.
Im Tooling.
Ja.
Ja.
Genau, jetzt...
Ja, also jetzt sind wir quasi schon in der Pause und den Rest werden wir wahrscheinlich morgen machen.
Ich wollte aber doch mal ganz kurz auf den Workshop eingehen.
Ich habe da gestern eben so ein bisschen drüber geskript, einfach weil...
Ich Sarah nicht direkt verjagen wollte.
Es war tatsächlich dieses Agent-Ding, wie man das halt macht, ja, ist halt Agents aneinanderhängen und überpompting.
Das ist sehr spannend, dass man halt Agents fragt, was Agents machen sollen mit dem Ergebnis und dann halt verschiedene Queries bereitstellt.
Das ist aber eigentlich auch so nicht so viel Neues, aber ich weiß nicht, würdest du das auch so machen?
Ich weiß es nicht so genau.
Ich habe mich noch nicht so richtig mit diesen ganzen Geschichten beschäftigt.
Ich weiß nicht, ob ihr mir das schon mal angucken wollt, es gibt auch von Pidentic.
Gibt es da irgendwie so ein Projekt, irgendwie Pidentic Agents oder ich weiß nicht mehr genau, wie das heißt.
Das sah ganz interessant aus, dass man das halt damit so ein bisschen strukturierter machen kann.
Aber ich finde das vor allen Dingen blöd, dass die Namen da wieder so verwirrend sind, weil Agents in dem Hype-Kontext quasi oder so, wie es Leute jetzt gerade verwenden,
halt was ganz anderes bedeutet als in einem akademischen Bereich und da bedeutet es was ganz anderes, als was Leute vielleicht darunter verstehen.
Und dann...
Naja, es ist irgendwie schwer zu erklären, was das denn überhaupt ist.
Also ich meine, wenn man jetzt einfach sowas sagt, wie ist es halt LLM in der Loop, dann ist es relativ klar, ja ist okay, ist halt außenrum ein bisschen Logik und ab und zu fragt man halt in LLM nach irgendwelchen Regeln.
Ja, aber dann ist halt die Frage, ist das jetzt schon wirklich mehr als einfach nur irgendwie, man fragt halt die Apis von LLMs, warum nennt man das jetzt irgendwie, also was ist...
Ja, ich finde ganz ehrlich, diese ganz strikte Auslegung davon, dass nur das ein Agent ist, der selbstständig irgendwelche Sachen macht.
Ja, der unter seiner Identität irgendwie Dinge tut.
Und das ist ja meistens dann überhaupt gar nicht so, sondern eher...
Ja, aber ich finde, da sollte man vielleicht nicht ganz so streng sein, weil wenn das Ding halt schon dann halt so einen Act-Prozess hat, weil du halt diese Tools mit Python-Funktionalität verbinden kannst, dann ist es ja im Prinzip genau das, was du willst.
Ja, du hast halt manche Teile von deinem Code sind halt in LLM, das halt...
Genau, und das heißt, du kannst aber dann tatsächlich genau beim LLM diesen einen, ob man jetzt Assessor nennt oder wie auch immer, über dein JSON-Result von dem LLM parsen lassen und sagen kann, welche Funktionen...
Und dann kannst du halt dann da schon echte APIs anbinden, wo du halt dann eine Autonomie, also so weit herstehen kannst, wie weil du selber mit deinem Tango in der Lage bist, externe Dinge zu steuern.
Und das ist ja schon irgendwie Agentik oder sowas.
Ja, ist alles noch sehr, sehr neu, aber ja.
Ja, also ich finde, das ist schon...
Ist aber natürlich, ist schon interessant.
Mehr Agentik als andere Dinge.
Ja, keine Ahnung.
Also ja...
Du hast ja schon gesagt, wo wir sind. Wir sind hier in diesem...
Wir sitzen in der Lobby von dem Hotel.
In der Lobby von dem Hotel. Vielleicht hört man ein bisschen hinterher Geräusche oder auch Phonic hat einen sehr guten Job gemacht, dann hört man nichts mehr davon.
Das wissen wir aber jetzt noch nicht.
Das wissen wir jetzt noch nicht.
Ja.
Ja, es gibt ja heute noch ein paar Vorträge über Software-Quality. Ich habe mir noch ein paar so Sachen rausgeschrieben, über eine Python-Mystery, über Celery, über die Baute, die wir benutzen und dann natürlich noch Lightning-Talks.
Und Lightning-Talks.
Nicht sehr gespannt. Lightning-Talks ist immer gut.
Du wolltest auch einen Lightning-Talk machen, darüber, wie man fünf Minuten einschlafen kann, habe ich gehört.
Das weiß ich noch nicht, ob ich mich traue.
Ich wäre gerne direkt am Anfang eingeschlafen von dem Lightning-Talk.
Ich habe ja nur fünf Minuten dann in dem Lightning-Talk. Also es könnte, wenn dann alle schlafen, dann raube ich natürlich direkt alle Laptops weg.
Ja, also heute sehe ich das nicht mehr, aber generell ist das eine Experience. Ich habe das ja damals in Heidelberg schon gemacht und ich bin ja auch nicht scheu, jetzt was öffentliche Auftritte angeht.
Aber das ist generell eine Experience, die kann ich jedem empfehlen.
Und wenn jemand die Gelegenheit hat, einen Lightning-Talk zu sehen...
Oder zu geben, dann sollte man die auf jeden Fall wahrnehmen.
Und jetzt habe ich mich gerade selber überredet, oder?
Ja, ich würde sagen, wir können gleich morgen dann über den Lightning-Talk von Johannes noch berichten.
Sehr gut.
Cool.
Okay, dann haben wir heute tatsächlich eine kurze Folge für euch gehabt.
Ja.
Vielleicht die Woche wieder. Wir wollen, wie gesagt, nicht versprechen.
Nee, aber möglicherweise.
Für heute hat es schon mal Spaß gemacht. So einen kleinen Sneak-Peak auf die Jungle-Con nebenbei.
Ja.
Dann schaut ihr rein.
Hallo, der Python-Podcast hier für jedes Feedback.
Wünsche euch was. Bis bald.
Tschüss.
Tschüss.