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, Jochen.
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 passiert und das vielleicht auch
in den nächsten Tagen 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 wir ein bisschen später
dran waren beim Release.
Und das machen wir diesmal nicht.
Sondern wir erzählen euch einfach ein bisschen, wie es hier so ist.
Wir lassen den News-Tag diesmal weg.
Und gucken, was passiert.
Genau.
Ja.
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 habe gehört, es war average.
Ja.
Das ist aber...
Ja.
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.
Ja.
Von oben.
Ja.
Alles durchschnittlich.
Nochmal alles irisches Wetter.
Ja.
So war unser erster Eindruck gestern.
Ja.
Wir sind nämlich auch alle im gleichen Flugzeug gekommen.
Das fand ich auch sehr lustig.
Ja.
Der Abschluss wäre ein großer Verlust gewesen, wenn ein Drittel von den Passagieren
irgendwie wegen der DjangoCon 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.
Es ist natürlich auch total schwierig, weil man traut sich das erstmal gar nicht zu.
Warum sollte ich jetzt unbedingt so das große Django-Reviewen machen?
Aber das, was du gesagt hast, macht doch einfach mit.
Ja.
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 so?
Seit einem 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.
Ich hatte immer das Gefühl, dass
Review so ein bisschen
die Schranke ist, dass da
ein Gatekeeper steht,
der 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 mehr
als ein Mann
das Pull-Request
Review machen kann.
Wir können vielen Leuten
ihre Meinung
sprechen, dass
diese Feature
gefällt mir oder nicht.
Es gibt ja so
verschiedene Seiten, von denen man das sehen kann.
Jeder hat ja so einen eigenen Stil.
Da gefällt anderen Leuten
andere Dinge auf.
Ja, klar.
Ja, aber gibt es
irgendeine Erkenntnis
darüber, warum das vielleicht so wenig,
warum Leute das nicht so gerne machen?
Könnte man die Motivation
leicht verbessern?
Ich weiß es nicht so genau.
Es ist schwer zu sagen,
warum man
das machen sollte, weil
es gibt
kein Geld,
und
das sie meistens auch nicht.
Und dann, du bist nicht die
Ose
von dieser Code.
Genau, der Ruhm und Ehre geht an den Menschen,
der diesen Code mitgeschrieben hat.
Ich weiß nicht,
warum es gibt
ein paar Leute,
die zu viel Zeit
investieren
schon, aber
ähm,
ob man ein paar
Stunden pro Monat
kann PR-Reviews
machen,
dann es kann
so viel für
Django
machen.
Die Django-Community profitiert auf jeden Fall
von
diesen Dingen. 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.
Ja, 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, ja, also ein Contributor's 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.
Ja.
In diesem Triage wird halt geguckt,
gibt es schon Tests, gibt es schon Dokumentationen,
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. Das ist schon
interessant, sich da so ein bisschen dran zu
deklinieren.
Es gibt halt so Teile, wo
die Innereien vom ORM
oder so, da geht es halt nicht.
Ich glaube, viele Leute würden da zurückschrecken
und denken so, oh, oh.
Da sind vielleicht auch nicht ganz so viele PRs
offen.
Genau, das ist ja auch interessant. Gibt es da irgendwie Tendenzen,
wo halt die meisten Pull-Requests
offen sind, oder ist es
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 Kern,
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
Fudjango 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 so die lieber, oder wo kommst du sie 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
des... Es war so ein Geben und Nehmen.
Ja, es war so ein Geben und Nehmen.
Einerseits habe ich natürlich,
wenn du einen 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
professionellen Kontext, weil im professionellen Kontext
hast du halt auch diese politische Ebene dazwischen,
dass man seine Kollegen immer dann
direkt mergt, weil man mag die ja und möchte
keinen Ärger haben.
Oder man ist nicht allzu kritisch.
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
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...
... und sagt ihnen, du, du, du.
Das darfst du aber nicht.
Mach das nicht nochmal.
Ja, aber wenn man Tests gehabt hätte...
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.
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.
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 spielt, ist ja schon ein Motivator.
Ich wünsche dir ein bisschen mehr Gamification.
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 5 PRs und sagen dann,
ich habe da was reingekriegt.
Aber niemand würde auf die Idee kommen, 5 Reviews zu machen.
Weil da kann man nicht drauf zeigen und sagen,
ich habe Review gemacht.
Und ich glaube, das ist einer von den Motivatoren,
die da einfach fehlt. Aber es ist auch so was
Unsichtbares.
Ein PR ist eine Sache und die
macht man und dann ist die da fü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.
Die sind dann einfach im Truck und das Truck wird dann
irgendwann irgendwas anderes migriert
und dann...
Also es ist einfach nicht sichtbar. Es ist nicht sichtbar,
dass jemand Review gemacht hat.
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,
dass Django machen kann für das?
Ja, es wurde ja vorhin auch schon
vorgeschlagen, oder es wurde vorhin auch schon angesprochen,
dass man einfach das sichtbar macht.
Okay.
Dass man sichtbar macht, wer Reviews macht.
Auch bei der ersten schon.
Du hast auch gesagt, es gibt eine Gruppe von Leuten,
die das, keine Ahnung, 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.
Also ich will Instant Gratification haben.
Ja.
Und ich glaube, wenn man das sichtbar machen würde,
dass es das gibt und
dass man dafür Punkte bekommt, egal welche 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.
Ja.
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.
Ich kann es nicht.
Keine Ahnung.
Ja, es gab ja noch die nächste Idee dann,
dass halt viele von den erfolgreich
reviewten Pull-Requestern irgendwie
kurz vor Merchandising bleiben, weil auch da ja
niemand da ist, der das hauptberuflich macht.
Und es hat nur sehr wenige
Merger gibt. Und wir hatten eben
die Diskussion draußen nochmal.
Also ich glaube, Karin Gipsen 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 Co total
super ist und die Dokumentation total toll ist.
Und ja, dann
kam halt wieder dieses Thema auf, wer mergt denn 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 Merchants gibt es?
Keine Ahnung. Also 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
Paros.
Aber die meisten
Pullrequests sind
merged bei die Fellows.
Vielleicht
Marisch
macht schon
ein bisschen mehr. Aber
ich weiß
nicht, weil es gibt
die
!
Die Entscheidung, dass
es ist
wirklich gut.
Und es ist auch die Entscheidung,
dass
ob etwas
falsch gemacht oder etwas
nicht so gut ist, dass
du das
besser machst.
Und du glaubst, dass
vielleicht diese
PR-Rotha
geht weg,
weil so viele Leute
bleiben.
nicht,
dann, ja, ich verstehe
die Code gut genug,
dass ich glaube, ich kann
das besser machen.
Und das,
keine Ahnung, wie
viele Leute
würden 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.
Und das ist
so, keine Ahnung.
Aber wir können
versuchen.
Das ist so ein Probe-Merch.
Ich habe das jetzt gemerkt.
Fandet ihr das auch okay?
Ja, es ist auf jeden Fall
ein schwieriges Problem.
Wir haben da ja auch gestern drüber gesprochen.
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
der reine Code.
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.
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
Dango-Poll-Requests oder sowas, dann kommt man
da relativ weit mit. Also auch
mit dem Reviewen von diesen Poll-Requests.
Ja, aber was da...
Naja, ich kann natürlich auch so ein Katzen-Maus-Schlüsseln.
Maus-Spiel werden dann.
Weil es wird dann möglicherweise...
Also du hast dann halt LNMs, die generieren
PRs und dann andere LNMs, die
quasi...
Und dann kann man auf beiden
Seiten aufrüsten. Aber irgendwie hilft das...
Vielleicht kommt ja dann tatsächlich ein ordentlicher
Poll-Request bei raus. Also das ist ja eigentlich das, was du willst.
Ja, gut. Von wem der dann kommt, ist ja dann fast...
Ist auch egal. Genau. Wenn es stimmen würde hinterher,
dann wäre es auch ein bisschen egal.
Ja, ich weiß es nicht. Vielleicht müssen wir uns 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 uninteressant.
Es war nicht ganz so viel Neues zu dem, was wir eh schon so machen.
Aber es ist schon
spannend, wie man
einen Agenten dazu bringt.
Wie wurde dann da Agents eigentlich definiert?
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 ein Loop-Bauen
für LNMs, die dann verschiedene
Tests durchgehen können und dann halt Funktionen aufrufen.
Und es gab aber dann halt
für eine Beantwortung eine Frage
am mehrstufigen Agentenprozess,
um bestimmte Sachen dann
to buy sind drin.
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?
Geht es 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 rausgefogen 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 mehrstufigen
Agenten beibringen. Aber auch das,
dass da wieder Arbeit, ja,
da weiß man so, hey,
wir brauchen tatsächlich 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.
Den Spenden-Link
posten wir auch.
Ja, ich habe tatsächlich
ab und zu mal so die CTOs
oder ein bisschen anderes Level noch
versucht zu bequatschen für, hey, wir benutzen
auch 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?
Okay, ja, weil
ohne das wird 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 lange
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 diesem Firma
sprechen und
sie möchten wieder
sponsoren.
Ja, aber es ist
ein schweres Thema.
Ob was...
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.
Was eigentlich ein bisschen schade ist,
weil es nicht so viele Public-Gedanken gibt.
Ja, aber im Großen und Ganzen steht
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 den anderen Weg,
so Laravel oder sowas, die dann
auf einzelne Leute mit viel Geld
gesetzt haben und das dann verkaufen, um
dann so einzige
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?
Ihr wart noch die ganze Zeit in der Main-Hall
und habt euch die Talks angeguckt.
Das war auch Senate.
Ja, das mache ich auch seit einiger
Zeit sehr, sehr gern irgendwie.
Ja, das wurde da auch angesprochen
mit HMX.
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.
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?
Genau, hat er noch 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,
den ich dann Playwright laufen lasse.
Ich weiß
nicht so genau. Also ich habe noch nicht so wirklich rausgefunden,
wie man das am besten macht.
Aber ja, also mein Weg
ist gerade halt einfach einen
Server 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 ist, wo man erwartet
in 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.
Alter, katsch. Danke, nicht so doof.
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 so? Wir hatten noch
diese unglaublich gute
War-Story von Tim Bell.
Ah, ja, ja. Über Datenbanken.
Ja. Jochen, da weißt du am meisten,
da hast 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
ja, also gerade die Namensgebung.
Also dann haben wir
eine Schattenspalte
irgendwie aufgemacht und dann Schattentabellen
und das, 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 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 halt die Tuppels, also
Postgres kopiert immer Tuppels,
ändert die Datenbank
Zeilen nicht wirklich,
sondern pügt dann neue Zeilen hinzu und markiert
die alte als, die kann jetzt weg. Und dann
muss hinterher der Flop-Sauger 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
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
renames 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 Wake-up
sparen kann, weil man die Tabellen, die man hinterher
umbenannt hat,
einfach nur droppen kann. Jetzt musst du einfach noch mal
kurz das über das Wake-up eingehen, bitte.
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 ist der Auflauger? 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.
Und deswegen vielleicht der Trick mit der,
man macht das halt
in einer Tabelle und dann schmeißt man die andere Tabelle einfach.
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 dann
genauso. Und
ja.
Sarah, geht gerade? Ja, vielen, vielen Dank.
Du musst noch Tschüss sagen, Sarah.
Du kannst nicht einfach reden.
Wir können ja einfach das Thema unterbrechen.
Wenn Sarah gerade los muss. Tschüss.
Vielen Dank.
Danke. Vielen Dank.
Danke schön. Vielen Dank.
Ciao.
Ja, und genau, das erinnert mich sehr stark an das,
was ich früher auch schon mal gemacht hatte.
Da hatten wir so ein bisschen so ein Preisvergleich gearbeitet.
Und da war es auch so, dann kommen dann halt
neue Daten von irgendwie einem Shop oder so.
Von Amazon kommt dann irgendwie eine Million neue Angebote
oder hat sich irgendwie der Preis geändert oder sonst irgendwas.
Und dann muss man halt das irgendwie ändern.
Und hatte dann auch das Problem, dass wenn man das halt
so sukzessive lang...
Dann dauert es halt ewig, was schlecht ist,
weil dann stimmen die Preise eine lange Zeit nicht.
Oder man macht alles auf einmal.
Dann steht das Produktionssystem, was halt auch schlecht ist,
weil dann verdient man auch kein Geld mehr.
Und dann muss man sich halt irgendwie
komische Dinge überlegen, bei denen man sich immer so fragt,
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,
dieser Vibe war bei diesem Tag
auch spürbar.
Ja, er hat auch gesagt,
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.
Und außerdem haben wir 292 Schritte
manuell machen müssen für 18 Datenbanken.
Und das war dann zwischendurch
so ein kleiner Aufwacher.
Ja, wie?
Ja, so ein...
Ah!
So viel manuelle Arbeit ist da drin.
Er hat dann ja auch von seiner
automatisierten Lösung erzählt.
Fand ich auch sehr interessant.
Würde ich mich auch so nicht trauen,
solche Sachen.
auf Datenbanken laufen zu lassen.
Auch für Monate.
Ich musste auch nochmal mit ihm sprechen und ihn fragen,
wie sie sicherstellen, dass während dieser Prozess läuft,
dass dann keine anderen Sachen
passieren.
Weil er am Anfang seines Vortrags
angedeutet hat, dass sehr häufige
Deployments auf sehr viele verschiedene Systeme machen.
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 ist auch schon
zwei, äh,
auf jeder Django-Konferenz.
Er macht auf jeder Django-Konferenz.
Das war der dritte Teil.
Und er hat auch gleichzeitig
drei veröffentlichte Bücher.
Ah, deswegen drei.
Genau.
Das war wie immer super. Er hat halt einen Haufen
Detail-Informationen darüber,
was man so an Indizes
benutzen kann, wie man das in Django macht
und so. Genau, also im Endeffekt ging es darum,
wie man Datenbanken identifiziert hat.
Datenbanken-Reads schneller zu machen und
das Mittel der Wahl des 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
wo was SQL in die Mutation reinschreiben.
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?
In die Meta-Klasse kannst du Indizes
angeben, die für die Tabelle gelten sollen.
Genau, und da hat der dann einen extra Feld gemacht,
was der 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 musst du 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
das 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, dass 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.
Was ist PG Mustard?
Senf. Ja, ja,
aber das ist so ein
Tool, das dir dabei hilft, deine
Statements
zu optimieren. Diese Explains
sind ein sehr komisches Format.
Ja, die sind komisch zu lesen. 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.
Tatsächlich gar
nicht so kompliziert.
Das hätte gesagt, 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 einen Teil der Queries
halt irgendwo hat, dass man halt ein repräsentatives Sample
der Queries, die so auf der Datenbank laufen, halt
irgendwo mitloggt.
Aber ja, das müsste man
dann auch irgendwie in diese... dass man dann ein Explains
drauf macht, keine Ahnung. Das müsste man dann noch
wahrscheinlich selber machen, aber...
Also da sind noch Lücken
im Tooling.
Ja, genau.
Ja, also jetzt sind wir quasi schon in der Pause.
Den Rest werden wir wahrscheinlich morgen machen.
Ich wollte aber doch mal ganz kurz auf diesen 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.
Was ich mir schon mal angucken wollte, es gibt auch von
Pydentic, gibt es irgendwie so ein Projekt
irgendwie, Pydentic Agents,
oder ich weiß nicht mehr genau, wie das heißt.
Das sah ganz interessant aus, dass man das
halt damit so ein bisschen
strukturiert,
strukturierter machen kann, aber
ich finde das vor allen Dingen blöd, dass das halt die
Namen da wieder so verwirrend
sind, weil Agents in dem Kontext,
in dem Hype-Kontext quasi, oder
so wie es die 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 einem Loop,
dann ist es halt 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 Abis
von LLMs, warum
nennt man das jetzt irgendwie, also wo,
was ist, wenn man die Agents nennt?
Ja, ich finde 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. Ja, aber ich finde,
da sollte man vielleicht nicht ganz so streng sein, weil
wenn das Ding halt schon
dann halt so ein
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, manche Teile von deinem Code
sind halt in LLM. Genau, und das
heißt, du kannst aber dann tatsächlich genau beim LLM
diesen einen, ob man ihn jetzt Assessor
nennt oder wie auch immer, über dein
JSON-Result von dem LLM
parsen lassen und sagen kann, welche
Funktion denn dann mit welchen Argumenten ausgeführt werden soll
und dann kannst du halt dann da schon
echte Abis 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
neu, aber ja.
Ja, ich finde, das ist schon...
Mehr Agentik als andere Dinge.
Ja, keine Ahnung.
Also ja...
Haben wir eigentlich schon gesagt,
wo wir sind? Wir sind hier in diesem
Troll... Wir sind in der Lobby von
dem Hotel. Vielleicht hört man ein bisschen
Geräusche oder auch Phonik 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, 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 Worte, die wir benutzen
und dann natürlich noch Lightning-Talks.
Und Leute, nicht sehr geschüttelt, Lightning-Talks ist immer gut.
Du wolltest auch ein Lightning-Talk machen, darüber, wie man
fünf Minuten einschlafen kann, habe ich gehört.
Das weiß ich noch nicht, aber ich mich traue.
Ich hätte gerne direkt am Anfang
eingeschlafen von dem Lightning-Talk.
Ich habe ja nur fünf Minuten
in dem Lightning-Talk. Also es könnte,
wenn dann alle schlafen, dann raube ich natürlich direkt
alle Laptops weg.
Aber ja, also heute sehe ich sie 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 über den Lightning-Talk
von morgen
von Johannes noch berichten.
Sehr gut.
Okay, dann haben wir heute tatsächlich eine kurze
Folge für euch gehabt.
Vielleicht die Woche wieder.
Wir wollen wie gesagt nicht sprechen.
Aber möglicherweise.
Für heute hat es mal Spaß gemacht. So einen kleinen
Sneak-Peak auf die Dangekorn nebenbei.
Dann schaut ihr rein. Hallo at peisenpodcast.de
für jedes Feedback.
Bis bald. Tschüss.