Transkript: Live von der DjangoCon Europe 2025 in Dublin - Tag 1
Vollständiges Transkript der Episode. Zeitstempel beziehen sich auf die Audiowiedergabe.
Ja, hallo, herzlich willkommen beim Python Podcast, Episode 63.
Heute gibt es eine Sonderausgabe.
Wir sind nämlich auf der DjangoCon in Dublin.
Ja, und wir sind 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.
Lasst den News-Ter 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 es 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.
Ich hab gehört, es war average.
Ja.
Es war schon so, dass man so, 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 durchschnittlich.
Also seid froh, wenn ihr gerade im Trocknen sind.
Das hat auch auf den Tisch getroffen, ein bisschen von oben.
Alles durchschnittlich.
Normales irisches Wetter.
So war unser erster Eindruck gestern.
Ja, wir sind nämlich auch alle mit dem gleichen Flugzeug gekommen, das fand ich auch sehr lustig, dass da irgendwie so viel große Drittel von den Passagieren irgendwie wegen der Django-Con darüber geflogen ist.
Ja.
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 ein 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?
Aber das, was du gesagt hast, Sarah, war, mach 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.
Genau.
Eine Position, wo eine Person bezahlt wird, um an Django zu arbeiten.
Vollzeit.
Das heißt, wie lange machst du das schon, Sarah?
Seit einem Jahr.
Seit einem Jahr schon.
Okay.
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, 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, es ist, ähm, ich hoffe, dass es mehr als ein Mann gibt, das einen Pull Request Review machen.
Und wir können viele Leute unsere Meinung sprechen, dass diese Feature gefällt mir oder nicht.
Und es gibt ja so verschiedene Seiten, von denen man das sehen kann.
Also jeder hat ja so einen eigenen Stil und dann gefällt anderen Leuten, fällt natürlich andere Dinge, fallen ihnen 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 da die Motivation leicht verbessern oder so?
Ich weiß es nicht.
Sarah sagt, es dauert lang.
Klar, es gibt, es ist schwer zu sagen, warum man das machen sollte, weil es gibt keine Geld und
deswegen mache ich es übrigens auch nicht.
Und dann du bist nicht die Author von dieser Code.
Die Ruhm und Ehre geht an den Menschen, der diesen Commit geschrieben hat.
So ich weiß nicht, warum es gibt ein paar Leute, dass so viel Zeit investieren schon, aber um ein paar Stunden pro Woche pro Monat can or PR or Trial.
You know, PR Reviews machen, then it can so feel for Django machen.
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.
Es gibt einen Endpunkt, also code.jangoproject.com, wo man dann halt die offenen Pull Requests sehen 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 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.
Gerne.
Und diesen Triage-Projekt 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 Dango gibt, die alle auch einen unterschiedlichen Stil haben.
Also wahrscheinlich, weil unterschiedliche Leute daran geschrieben haben.
Darfst du herauszufinden?
Das ist schon interessant, sich da so ein bisschen dran zu dem Tanner.
Es gibt halt so Teile, wo ich ja, also so 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 Pairs offen.
Das wäre auch interessant.
Gibt es da irgendwie Tendenzen, wo halt die meisten Pull-Requests offen sind?
Oder ist es komplett über die Codebasis verteilt?
Es gibt viel für die ORM.
Es ist ein sehr
großer Teil.
Ja, genau.
Und es ist 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 beste Reviews und viele seid.
Es fühlt sich 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.
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 das einfach ein Teil des Teams ist.
Es war so ein Geben und Nehmen.
Es war so ein Geben und Nehmen.
Einerseits habe ich natürlich, wenn du einen PR stellst, erwartest du in einem, gerade im 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 ist.
Open Source vielleicht noch ein bisschen anders als im professionellen Kontext, weil im professionellen Kontext hast du halt auf diese politische Ebene dazwischen, dass man seinen Kollegen immer dann direkt merged, weil man mag die ja und möchte keinen Ärger haben.
Oder man sind
längere Teams, also wenn du mit zehn Leuten zusammenarbeitest, ist das was anderes, als wenn du im Open Source Projekt mit tausend Leuten zusammenarbeit.
Und was man bei einer Firma oder so auch oft machen kann, ist, dass man einfach erst mercht und dann reviewt.
Das ist jetzt bei Django vielleicht eher schlecht.
Ja, weil wann seine Kollegen etwas kaputt machen, dann spätestens.
Dann holt man sie sich und sagt ihnen,
das darfst du aber nicht.
Mach das nicht nochmal.
Ja, aber wenn man Tests gehabt hat, dann 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, dass das auch super war.
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 drinstehen.
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 Möglichkeit.
Und da mehr Gamification für deinen Pull-Requests.
Ich weiß, dass
bei mir funktioniert und ich weiß, dass das bei vielen anderen Leuten funktioniert.
Und es ist ja auch was wert, ja.
Es ist auch was wert.
Das hast du auch in deinem Vortrag gesagt.
Wenn jemand, bevor sich die Leute für Summer auf Code vorbereiten, machen sie schnell noch mit 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 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 sowas Unsichtbares.
Es ist nicht ein PR ist eine Sache und die ist, die macht man und dann ist die dafür immer.
Und diese Review ist sowas, ich hab dir ein paar Kommentare gesagt.
Und die werden ja auch unter Umständen gar nicht Teil des Repositories, sondern.
Genau, die sind dann einfach im Truck und das Truck wird dann irgendwann irgendwas anderes migriert und dann oder so.
Es ist einfach nicht sichtbar.
Es ist nicht sichtbar, dass jemand Review gemacht hat, dass es nicht, es gibt keinen Punkt, den man dafür kriegt, kein Sternchen, ja.
Ruhm und Ehre der Community.
Ja, natürlich, es verbessert das, aber das reicht offenbar.
Denkst du, es gibt etwas, das 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, Reviewer-Bit haben oder wie auch immer, die dann halt da aufgehört sind.
Aber das ist für mich jetzt als eins, 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.
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
umgekehrt muss man natürlich auch aufpassen, dass das nicht so Leute anzieht, die dann sagen, ja, ja, ja, ja.
Shai Burger hat mir gesagt, dass es gab ein Dinger für die Core Team.
Es gibt kein Core Team jetzt, aber vorher, man muss fünf PR-Reviews machen und dann ihre PR kann ein Review haben.
Und das hat eigentlich funktioniert, Shy gesagt.
So vielleicht das ist auch eine Idee, dass wir das wiedermachen oder etwas ähnlich.
Ja, es gab ja noch die nächste Idee dann, dass halt viele von den erfolgreich reviewten Full-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, Klaien Gibson hat gesagt, so, hey, was hältst du denn davon, wenn es mehr Leute gibt, die mergen?
Und wir haben uns draußen unterhalten und sagt, so 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 merken das.
Und das wäre natürlich auf einmal sehr aufpassen, wer das dann ist.
Weil sonst hast du halt Sachen drin, die dann vielleicht nicht so passen.
Und wie viele von diesen Menschen es gibt, keine Ahnung.
Also was hältst du davon?
Also du hast eben gesagt, du weißt es nicht, genau.
Also es gibt jetzt vier Merges.
Es gibt die Fellows, ich und Natalia.
Ich glaube es gibt Marisch Feliciak und Claud Poros.
Aber die meisten pull requests sind merged by die Fellows.
Vielleicht Marisch macht schon ein bisschen mehr.
Aber ich weiß nicht, weil es gibt die Entscheidung, dass es wirklich gut ist.
Und es ist auch die Entscheidung, dass ob etwas falsch gemacht oder etwas nicht so gut ist, dass du kannst das besser machen.
Und du glaubst, dass okay, vielleicht dies dieser PR oder geht weg, weil so viele Leute bleibt 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ü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.
Ein bestimmtes Level von Commitment und das dann durch.
Aber wir können versuchen.
Ich habe das jetzt gemerkt.
Fandet ihr das auch okay?
Ja, es ist auf jeden Fall ein schwieriges Problem.
Und das ist wieder so ein, wir haben da ja auch gestern drüber gesprochen, ja.
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, 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-Pull-Requests oder sowas, dann kommt man da relativ weit mit, also auch mit dem Reviewen von diesen Pull-Requests.
Ja, aber was er nicht machen guckt.
Das kann natürlich auch so ein Katze-Maus-Spielen-Spiel werden, weil es wird dann möglicherweise, also du hast dann halt LLMs, die generieren PRs und dann andere LLMs, die quasi.
Und dann 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.
Ja, gut.
Von wem der dann kommt, ist der dann fast.
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 uns einfach ausprobieren, keine Ahnung.
Ja.
Vielleicht ein kleiner Übergang von dem Thema von Serrat, weil es gab noch so einen Workshop, wie man Agents macht.
Das war ja 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 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 ein Loop-Bauen für LLMs, die dann verschiedene Prozesse durchgehen können und dann halt Funktionen aufrufen.
Und es gab halt aber dann halt für eine Beantwortung einer Frage einen mehrstufigen Agentenprozess, um bestimmte Sachen dann zuweisen zu können.
Was man halt auch für so einen Pull-Request machen könnte.
Könnte halt gucken, hey, hier sind die Dogs drin und so weiter, sind die denn da?
Hast du einen Verbesserungsvorschlag für die Dogs?
Gehst du den 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 das fixst, 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 wieder Arbeit, ja.
Wo wir wieder dabei sind, so ey.
Wir brauchen tatsächlich für diese Open-Source-Geschichte so ein bisschen mehr Funning.
Und das ist auch die Frage, woher das kommt.
Also da gibt es so verschiedene Gates, die wir kennen.
Ja, aber alle unsere Zuhörer werden ja jetzt gleich losgehen und PRs reviewen.
Ja.
Und auch an die DSF-Spenden.
Genau.
Den Spendenlink pusten wir auch, meine ich.
Oh ja, den sollten wir da auch rein tun, ja.
Das ist richtig.
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 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.
Also 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 ja 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 konnten.
Aber es ist nicht so lang, seit dieser Team gegründet war.
Keine Ahnung, was sie machen jetzt.
Aber hoffentlich haben wir ein paar Sponsors und jedes Jahr.
Ich glaube, Catherine von DSF wird wieder mit diesem Firma sprechen und ob sie möchten wieder sponsieren.
Ja, aber es ist ein schwere Thema, ob was
ich glaube, die Sponsoren meistens sind das halt auch Leute, die man dann auch persönlich gut kennt.
Ja.
Und wo man halt eine Beziehung über ein paar Jahre oder aufgebaut hat schon.
Was eigentlich ein bisschen schade ist, also was es nicht so diesen Public-Gedanken gibt.
Ja, aber im Großen und Ganzen steht die Jungle Software von Deutschland ja schon vergleichsweise gut da.
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 andere 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 Laravell 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.
Playwright angeguckt.
Das war auch sehr nett.
Ja, das ist, äh, mache ich auch seit einiger Zeit sehr, sehr gern.
Irgendwie, ja, das wurde da auch angesprochen mit HMX.
Hat man ja 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, ähm, Jakob.
Jakob, äh, genau, hat er noch gesagt, ja, das hat er jetzt so gezeigt, aber das macht er normalerweise nicht so und ich mach 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.
Also ich habe noch nicht so wirklich rausgefunden, wie man das am besten macht.
Aber ja, also mein Weg ist gerade halt einfach ein 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 sitzt, wo man erwartet in verschiedenen Ansichten.
Ja, das war eine sehr interessante Sache.
Aber das war mehr so ein Denkanstoß, fand ich.
Ja, es war auch kurz irgendwie so, so jetzt geht's los.
Und dann so, alles.
Danke, nächster Doctor.
Aber es ist auf jeden Fall ein sehr interessantes Thema und ja, also schon faszinierend, was da alles passiert.
Was hat man denn noch so?
Wir hatten noch diese unglaublich gute Warstory von Tim Bell.
Ah ja, ja.
Über Datenbanken.
Ja.
Joachim, da weißt du am meisten, da hast du am meisten Schmerz gehabt in dem Vortrag.
Du weißt ja der Rennerbank auch schon so viel.
Ja, aber ich hab das, das war jetzt alles total lange her, dass ich viel mit Datenbanken gemacht habe, aber ja, also gerade die Namensgebung.
Also dann anfängt, dann haben wir eine Schattenspalte irgendwie aufgemacht und dann Schattentabellen und das, genau, so hatten wir das damals auch genannt.
Und ja, 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 es halt schon blöd.
Und wenn man jetzt halt irgendwie viele Sachen ändern will, dann einmal 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 Tuppels, also Postgres kopiert immer Tupels, ändert die Datenbank Zeilen nicht wirklich, sondern fügt dann eine neue Zeile hinzu und markiert die alte als die kann jetzt weg.
Und dann muss hinterher der Stoppsauger rüberfahren und die alle aufsaugen und das dauert halt auch lange.
Und ja, das ist halt eine komplizierte Geschichte.
Und wenn man dann halt viele Daten hat und so, 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 replaced das hin 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, wenn man die Tabellen, die man hinterher umbenannt hat, einfach nur droppen kann.
Jetzt musst du einfach nochmal kurz das über das Vacuum eingehen, bitte, weil.
Ja, also Postgres hat halt so einen Output-Vacum-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 so groß wird und nicht mehr ein 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 das in einer Tabelle und dann schmeißt man die andere Tabelle einfach raus.
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 übertragt auf die neue.
Und wenn man das mit Tabellen macht, ist es ein Grund genauso.
Und ja,
Sarah geht gerade?
Ja, vielen, vielen Dank.
Also du musst noch Tschüss sagen, Sarah.
Du kannst ja nicht ja vorgehen, wir können ja einfach das Thema.
Wenn Sarah gerade los muss.
Tschüss, tschüss.
Vielen Dank.
Danke.
Dankeschön.
Vielen Dank.
Ciao.
Ja, und genau, das erinnert mich sehr stark an das, was ich früher auch schon mal gemacht hatte, hatten wir da so einen Preisvergleich gearbeitet und da war es auch so, dann kommen dann halt neue Daten von irgendwie in 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 hat dann auch das Problem, dass wenn man das halt so sukzessive langsam, dann ist es, dauert es halt ewig, was schlecht ist, weil dann stimmen die Preise eine lange Zeit nicht.
Oder macht es alles auf einmal, dann steht das Produktionssystem, was halt auch schlecht ist, weil dann verdient man auch kein Geld mehr.
Und da 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, dieser Wein war bei diesem Tag auch schwörbar.
Ja, er hat auch gesagt, dass es, also er hat es 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 und für 18 Datenbanken.
Und das, äh, das war dann so zwischendurch so ein kleiner Aufwacher.
So ein Jagi.
Ja, und 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 sich dann sicherstellen, dass während dieser Prozess läuft, dass dann keine anderen Sachen passieren.
Weil er am Anfang seines Vortrags angedeutet hat, dass sie 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.
Ich meine, 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, vielleicht war das eine Tradition.
Er macht auf jeder Django.
Vorteiliges war der drei, genau.
Ja, das
ist der Bute.
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 hatte halt einen Haufen Detailinformationen darüber, was man so an NDCs 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 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 RosSQL in seine Migrationen reinschreiben.
Hatte ich auch gedacht, das wusste ich.
Was ich auch schon gesehen habe.
Aber auch die
Mal gebracht.
Wie macht der das dann?
Hat der ein Index-Field gemacht oder was?
Wo er dann da bestimmte Sachen reingeschlägt?
In der Meta-Klasse kannst du Indizes angeben, die für die Tabelle gelten sollen und für das Modell
gelten sollen.
Genau, und da hat er 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 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 den 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 damit 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 ein JSON zurück und dann kann man dieses JSON nehmen und dann in PG-Mustard reinschmeißen.
Was allerdings nicht Open Source ist?
Nee, stimmt genau.
Und was
ist PG-Master?
Senf.
Das ist so ein Tool, das dir dabei hilft, deine Statements zu optimieren.
Diese Explains sind sehr komische.
Ja, die sind komisch zu lesen.
Das ist sehr schwer zu lesen.
Und PG Mastered 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.
Achso, der Schritt wäre ja tatsächlich gar nicht so kompliziert.
Dass der 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 loggen lassen, zum Beispiel, wenn man sagt, also man ab einem bestimmten Threshold von Zeit, ich weiß nicht mehr genau, wie es geht, ich weiß nur, das geht schon.
Man kann also Queries, die länger brauchen, als so, log 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 immer 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.
Ja.
Aber ja, das müsste man dann auch irgendwie in dieser Exp, dass man dann einen Explained drauf macht, keine Ahnung, das müsste man dann noch wahrscheinlich selber machen, aber ja.
Also da ist noch, da sind noch Lücken im Tooling.
Ja.
Genau, jetzt, äh, ja, also jetzt sind wir quasi schon in der Pause und den Rest werden wir wahrscheinlich morgen machen.
Ich wollte aber nochmal ganz kurz auf diesen Workshop eingehen.
Ich habe da gestern eben so ein bisschen drüber geskippt, 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 über Prompting.
Das ist sehr spannend, dass man halt Agents fragt, was Agents machen sollen mit dem Ergebnis.
Und dann halt verschiedene Querys bereits.
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 Paydentic, 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 strukturierter machen kann.
Aber ich finde das vor allen Dingen blöd, dass das halt die, dass die Namen da wieder so verwirrend sind, weil Agents in dem Kontext, in dem Hype-Kontext quasi oder so wie es Leute jetzt gerade verwenden, halt was ganz anderes bedeutet als im akademischen Bereich und da bedeutet es was ganz anderes, als was Leute vielleicht drunter 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 a Loop, dann ist es halt relativ klar, er ist okay, es ist halt außenrum ein bisschen Logik und ab und zu fragt man halt ein 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 wo, was ist das?
Ich finde es ganz einfach ein strikte Ausdegen davon.
Was ist das denn da?
Ja, der seine Identität irgendwie Dinge tut.
Und das ist ja meistens dann überhaupt gar nicht so, sondern ja, ja.
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.
Du hast halt manche Teile von deinem Code sind halt ein LLM, das halt.
Genau, und das heißt, du kannst aber dann tatsächlich genau beim LLM diesen einen, ob man die jetzt Assessor nennt oder wie auch immer, über deinen 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 APIs anbinden, wo du halt dann eine Autonomie, also so weit herstellen 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 schon interessant.
Mehr Agentik als andere Dinge.
Ja, keine Ahnung.
Ansonsten war es das an Vorträgen.
Haben wir eigentlich schon gesagt, wo wir sind?
Wir sind hier in diesem
Lobby von Phonic.
Oder Auphonic 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 Softwarequalität.
Ich habe mir noch ein paar Sachen rausgeschrieben, über eine Python Mystery, über Celery, über die Bound, die wir benutzen.
Und dann natürlich noch Lightning Talks.
Bin ich sehr gespannt.
Lightning Talks ist immer gut.
Du wolltest auch einen Lightning-Top machen darüber, wie man in fünf Minuten einschlafen kann, habe ich gehört.
Das weiß ich noch nicht, ob ich mich traue.
Also heute haben gerne direkt am Anfang angeschlafen von dem Lightning Topf.
Ich habe ja nur fünf Minuten dann in dem Lightning Talk.
Also es könnte ja, wenn dann alle schlafen, dann raube ich natürlich direkt alle Laptops weg.
Ja, das, also heute sieht es nicht mehr, aber das ist 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 beredet, oder?
Ja.
Ich würde sagen, wir können gleich morgen dann über den Lightning Talk von Johannes noch berichten.
Sehr gut.
Cool.
Okay, ja, dann haben wir heute tatsächlich eine kurze Folge für euch gehabt.
Bei uns gucken wir rein.
Vielleicht die Woche wieder, wir wollen, wie gesagt, nichts versprechen.
Nee, aber möglicherweise.
Feute hat es nochmal Spaß gemacht, so einen kleinen Sneak Peek auf Dijungekon nebenbei.
Dann schaut ihr rein.
Hallo der Kaisen-Podcast.de für jedes Feedback.
Wünsche euch was.
Bis bald.
Tschüss.
Tschüss.