Transkript: Live von der DjangoCon Europe 2025 in Dublin - Tag 2
Vollständiges Transkript der Episode. Zeitstempel beziehen sich auf die Audiowiedergabe.
Hallo liebe Hörerinnen und Hörer, willkommen beim Python Podcast.
Episode 64.
Heute nochmal von der Django Con.
Eine Sonderausgabe.
Ja, zweite Live-Episode.
Ja, freuen dich wieder dazwischen.
Hey Jochen.
Ja, hallo Dominik.
Hallo Johannes.
Und hey Ronny.
Hallo Ronny.
Hi, schön
hier zu sein.
Ja, schön, dass du da bist.
Ja.
Ja, wir wollten noch ein bisschen wieder von der Django Con erzählen, auf der wir gerade sind in Dublin.
Das hatten wir ja gestern schon getan.
Die Folge ist tatsächlich auch pünktlich online gegangen.
Danke.
Ja, fast pünktlich.
So nach dem Pappbesuch ist das immer so ein bisschen schwieriger, also das Hotelzimmer wiederzufinden und dann auch noch eine Episode online zu stellen.
Insofern, das ging nur so irgendwie.
Nee, ich habe noch meinen Sweater vermisst
und dann habe ich meinen Sweater gefunden.
Das war wahnsinnig gut.
Dann hatte ich aber meine Hotelzimmer-Eintrittskarte nicht.
Am ersten
Tag einmal alles mitgemacht.
Ja, und wenn man das Zimmer wechselt, ist auch schlecht.
Dann ist alles anders.
Ja, aber hat irgendwie alles geklappt.
Ja.
Wir haben ja gestern bis zum ungefähr Mittags halt ja erzählt, was du warst.
Was war denn gestern noch interessantes?
Oh, das ist der Notiz.
Tut mir leid, du warst schon bei heute, lieber Hannah.
Ich glaube, das erste, was wir tatsächlich gesehen haben oder zumindest teilweise gesehen haben, war HTMX.
Ja, da kamen wir gerade nach dem Podcast noch so rein.
Und ja, war solide, aber auch nichts Überraschendes oder so.
Ich weiß nicht genau, ob jemand von euch da irgendwas Neues gesehen hat
oder interessantes.
Dann wir die erste Hälfte verpasst haben.
Ja, stimmt, da kann man auch nicht so wirklich was zu sagen.
Und ich war kurz im Gym- und Bar-Bereich.
Also ich habe es gesehen und ich würde mich da anschließen.
Also ich fand es solide, wenn man sich nicht damit beschäftigt, hat auf jeden Fall super hilfreich.
Wenn man sich damit beschäftigt, hat, glaube ich, nicht allzu viele neue Dinge.
Kurze Sightnote, bevor du runtergehst.
Den Talk mittags von Sebastian, hatte dir den besprochen, weil der ist ja auch aus der Region bei uns, aus Köln.
Achso, den hatten wir nicht besprochen.
Nee, hat man nicht gesprochen, den haben wir gedacht, genau dabei haben wir auch noch.
Ja, dann.
Genau, da
freue ich mich aber ein bisschen, dass es geklappt hat, weil er hatte mich noch gefragt, weil ich ja schon mal letztes Mal bei der DjungoCon mich beworben hatte und genommen wurde, wie es denn aussieht und ob er meint, dass die Idee, ob ich meine, dass die Idee fliegt und genau, fand das eine coole Sache.
Ich fand den Vortrag tatsächlich noch cooler.
Also für mich, ich habe mehr mitgenommen, als ich jetzt persönlich erwartet hätte noch.
Vielleicht erstmal kurz, worum ging es denn?
Sorry, sorry, natürlich.
Genau, also der hieß The Fine Print in Jungle Release Notes und es ging um neue Features in den neuen Versionen.
Also im Endeffekt der Aufhänger ist, liest die Release-Notes, abgesehen von dem einen mega krassen, geilen Feature, weil man halt da sehr viele Dinge immer kommen, die das Leben leichter machen, wo man Coach sparen kann, irgendwelche fiesen Hacks, Walkarounds ausbauen kann und hat sich dann dadurch die 5.x Versionen durchgehangelt.
Da waren tatsächlich Sachen dabei, die ich noch nicht gesehen hatte.
Ja, der Carlton hatte das ja vorhin auch so erwähnt, dass er auf keinen Fall wieder zu 4.2 zurückgehen würde,
wenn sich das schneiden lässt.
Genau.
Und genau, freut mich sehr, weil der ist jetzt auch bei einem Regular beim Cologne Meet, Django Cologne.
Was hat der denn alles Schönes erzählt?
Vielleicht kannst du so ein paar.
Ach, da fragst du mich Sachen, es ist immer so schwer, sich in Details zu erinnern, wenn man sich am Tag zählt.
Notizen hat wieder Johannes hier vor sich gemacht.
Ja, ich war aber nicht in dem Tag, deshalb habe ich keine Notizen zu dem Vortrag.
Da war ja was.
Es ging um diverse Verbesserungen im Admin.
Es ging um Custom Error Messages, die man jetzt bei Constraints hinterlegen kann, die auch übersetzbar sind.
Ah, cool.
Und es waren im Endeffekt alles relativ kleine Dinge, aber immer auf Use Cases bezogen, wie sie es halt vorher gelöst haben und nachher.
Also es waren ganz, ganz, also selbst wenn man jetzt sagt, oh, diesen Case hatte ich noch nie, muss noch nie eine Custom U-weiß ich nicht, Custom Unique Constraint definieren, dann war er immer so, ah, aber das sieht tatsächlich nützlich aus, weil diesen Fall kann ich halt vorstellen, weil man ihn halt präsentiert bekommt.
Also wie gesagt, das war deutlich, auch für mich, deutlich nützlicher, als ich es mir eigentlich vorgestellt hatte.
Weil ich dachte eigentlich, ich weiß schon alles, aber tatsächlich habe ich schon mal das Frontbild auch nicht so genau gelesen.
Ja, dann hat er das gut gelöst.
Das ist ja aber auch wirklich so eine Sache, dass in vielen Frameworks hat man ja diesen Death by a thousand Papercuts.
Das sind einfach viele, viele kleine Sachen, die gut oder nicht so gut sind.
Und ich glaube, dass das tatsächlich eine der Stärken von Django ist, dass die halt auch an diesen Kleinigkeiten arbeiten und danach sagen, wir haben an diesen Kleinigkeiten gearbeitet und dass die sich dann so langsam
mit der Zeit auflösen.
Ich kann ja auch nochmal in diesem Kontext erwähnen, dass ich jetzt in 5.2 meine erste Django Contribution drin habe.
Oh, herzlichen Glückwunsch.
Was bringst du uns denn?
Ich habe für im Zuge von meinem PonyExpress-Package, habe ich nach der DjangoCon Beagle einen Vortrag darüber gehalten.
Das ist ein Package, was E-Mailing ein bisschen vereinfacht, also wirklich die programmatische Erstellung und Testen von E-Mails, was ich relativ verbose finde, wenn man das mit den gegebenen Django-Tools macht.
Und fürs Testing, eine E-Mail hat ja nicht nur Text, sondern die hat ja verschiedene Texts, also Inhalte, also die kannieninhalte, theoretisch Medieninhalte haben.
Es gibt einen HTML-Inhalt und den Plain-Text-Inhalt, die sind, glaube ich, die relevantesten für die meisten modernen E-Mail-Clients.
Und man musste im Endeffekt wirklich manuell sich durch ein multidimensionales Dictionary in den E-Mail-Alternatives durchgraben, wenn man das testen möchte.
Dafür haben wir eine Package für die Test-Suite einen Wrapper geschrieben, also die Test-Suite nicht fürs Package, sondern wenn für die E-Mail-Klassen, die man produziert mit dem Package.
Und hab dann vorgeschlagen, ob das nicht ein relativer No-Brainer wäre, wenn man sowas auch irgendwie dem E-Mail-Alternatives geben könnte.
Dass es quasi alle, also diese, wie nennt man das?
Dieses Text slash, JavaScript, Script Slash, irgendwas, diese, ich komme gerade nicht drauf, diese Nine-Types.
Diese Content-Types, sorry.
Content Types, genau.
Ja, achso, Content Types.
Ja, genau, Content Types, dass man quasi alles, was mit Text Slash anfängt und was man hinzugefügt, was in 99% der Fälle wahrscheinlich immer nur Plain und HTML sein wird.
Trotzdem, dass man das dann aus dem Objekt zurückbekommt und dann halt im Test sehr einfach darauf versorgen kann, ohne halt sich durch irgendwelche nicht dokumentierten APIs durchzugraben.
Und genau, das ging auch tatsächlich relativ gut durch.
Ich habe dann nochmal was anderes probiert nach meinem Erfolgserlebnis und hab dann genau gemerkt, was Carlton heute in seinem Vortrag.
Ich greife vor, aber was er sagt, kann ich nachher nochmal meine persönliche Erfahrung dazu spiegeln.
Ja, da
werden wir auf jeden Fall gleich nochmal eingehen.
Das ist doch das Thema von gestern, was wir dann, glaube ich, nochmal ein bisschen aufmachen, wo es umgeht, wie man denn partizipieren kann an Django.
Aber vielleicht machen wir chronologisch weiter mit dem Talk.
Das ist dann vielleicht mal extra eine gute Idee.
Ja, der nächste war Solving a Python Mystery.
Oder war jemand bei dem Quality-Workshop?
Da war ich auch nicht drin.
Nee, leider nicht.
Wollte ich zwar auch
irgendwie, aber irgendwie hat es nicht.
Das hat nicht gepasst.
Genau, der war groß.
Aber der war gut.
Der war sehr gut, insofern ich den jetzt anwenden könnte, aber einfach mal mit S Trace überall reingucken.
Ja.
Und schaut, was dafür Dateien offen sind und so.
Ja, da ging
es, genau, da ging es hauptsächlich um so Dinge, die man halt, also was ist, wenn man ein Produktionssystem hat, wo man nicht so gut drauf gucken kann.
Man hat bloß halt vielleicht Logfiles oder man kann nur extern drauf gucken, man kommt nicht in die Prozesse rein.
Ja, oder hat man
eine geschränkte Shell drauf, sowas.
Ja, aber man kann halt, ja, also zum Beispiel, man hat einen Docker-Container, wie kommt man an das Environment?
Halt über das Pro-File-System kommt man, kommt man da halt dann ran.
Und dann hat man die ganzen Credentials, die man so braucht, um halt in die anderen Sachen rein reingucken zu können.
Und dann kann man viel mit S-Trace machen.
Und ja, das mache ich auch sehr gern.
Und naja, es gibt halt noch so ein paar andere Sachen, die man sich halt auch sich angucken muss, so wie viele I.O.-Operationen pro Sekunde gibt es denn eigentlich auf der Maschine?
Was macht die denn, was schreibt die, was liest die denn so?
Und er hatte, ich glaube, das erste Beispiel, was er hatte, war irgendwie ein Kafka, was irgendwie 25 Messages pro Sekunde gemacht hat oder so und alle waren so halbwegs zufrieden.
Das ist übrigens auch etwas, was ich immer wieder sehe bei Kunden oder so, dass sie halt mit Dingen zufrieden sind, wo man sagt, Moment, das kann nicht sein.
Das ist einfach so weit, dass es mehrere Größenordnungen von dem entfernt, was man erwarten würde.
Das kann einfach nicht sein.
Aber oft wissen Leute halt nicht, dass das eigentlich irgendwie anders aussehen sollte und denken dann, ja, so ist das halt.
Und dann machen sie halt ein Kafka-Cluster, statt halt mal zu gucken, warum das nicht richtig funktioniert.
Dann, genau, war da halt so eine Geschichte.
TCP, No-Delay kann man irgendwie setzen, wenn man
ja auch anstellen weiß.
Genau, macht Panel.
Kafka-Client macht's nicht.
Macht's irgendwie nicht.
Und dann sieht man so ein typisches 40 Millisekunden-Delay irgendwie.
Und wenn man das irgendwo sieht, dann weiß man schon so, oha, genau.
Und ja, solche Sachen halt.
Und was war das?
Was hat er noch alles erzählt?
Es war schon sehr weit runter in den Kernel.
Das war eigentlich das Interessante, dass der halt nicht Python debuggt hat, sondern er hat eigentlich Linux und File-Handles und Kernel-Traces debugged.
Von außen solche Sachen debuggen, das ist eigentlich super einfach.
Und dann hat er ein Diagramm irgendwie auf einer Site gezeigt und es ist halt ultra kompliziert, was er alles an Teilen irgendwie vom Kernel bis zu.
Und dann gibt es auch noch irgendwie EBPF-Trace oder so.
Es gibt ja dieses tolle neue Interface, da so Berkeley Packet Filter-Interface im Kernel, da kannst du halt auch tatsächlich die Sys-Call selber tracen.
Du kannst eigenen Code in den Kernel injecten.
Das wird ja an dem Belang.
Der dann im Kernel, vom Kernel, formal bewiesen wird, dass er nichts Böses tut und dann ausgeführt werden kann.
Ja, ja.
Und jemand, den wir auch schon im Podcast hatten, Martin hat dafür einen Python-Two, irgendwie diese Intermediate Language Compiler mal geschrieben.
Dann kann man das auch in Python machen.
Also das Ding ist total cool, der meinte auch, das verwendet er auch häufig, irgendwie, wenn er nochmal tiefer gehen muss.
Ja, ansonsten weiß ich, ich kann mich nicht mehr so wirklich erinnern an aller Details, aber es war halt so, ja, also man muss immer mal gucken und oft kann man halt mit so Standard-Linux-Tools irgendwie dann doch rauskriegen, was da irgendwie schiefläuft an Produktionssystemen.
Also ja.
Aber man merkte, der hatte richtig viel Erfahrung und schon eine Menge gesehen.
Mein Hauptgedanke war, ich bin dankbar für die Abstraktionsebene, die wir inzwischen unsere Berufswelt haben, dass das Dinge sind, mit denen ich mich einfach nicht beschäftigen muss.
Mein Gedanke war, dass ich dankbar bin, dass es so Leute gibt wie ihn, der das macht.
Ja, aber meinte auch erst halt so, wenn er irgendwo einen 500er-Fehler sieht oder sowas, dann er kann nicht mehr schlafen.
Man muss es irgendwie rauskriegen.
Das geht auch ohne Unix-Debugging.
Genau, ja, war sehr schön.
Danach war der Salary-Vortrag, also der Parallelisierungsvortrag mit Salary.
Den fand ich jetzt nicht so, der ist nicht so tief reingegangen, wie ich gedacht hätte, dass man kann.
Und für mich war es mehr so ein so eine Bestätigung, dass die Sachen, die ich rausgefunden habe, nicht ganz abwegig sind.
Ja, ja, ja, ja.
Und die wann?
Ja, dass du Tasks in möglichst kleine Teile aufteilst, dass du ein Modell hast mit einem Status drauf, dass du den Status atomal änderst.
Also in der Transaktion machst du ein Select for Update auf dieses Modell, änderst den Status, speicherst den, dann, das hat er nicht gezeigt, dann mache ich es normalerweise so, dass ich in dem Punkt die Transaktion beende, weil dann habe ich ja mein Modell in der Hand mit dem korrekten Status, dass ich kein anderer mehr nehmen kann.
Und dann kannst du diesen Task abarbeiten und dann hast du nochmal so einen Block, der dann den Status auf die nächste Stufe stellt, sodass es weiterverarbeitet werden kann.
Und dieses Muster, das ist sowas, da ich weiß nicht, vielleicht bin ich da als Einziger drauf gekommen oder auch nicht, ja.
Und dieser Vortrag war so ein bisschen die Bestätigung, ich bin nicht als Einzige drauf gekommen.
Das ist immer sehr gut, weil das eben bedeutet, dass man nicht was ganz Verrücktes macht.
Also du hast ein Statusmodell, das hält dann immer da, wo bist du denn gerade und das wird dann immer Transaktionen angefasst und du filterst dann auf Dinge, die auf dieses Statusmodell.
Ja, und wenn du in so einen Task reingehst, dann erwartest du, dass das Objekt, was du bearbeitest, in einen bestimmten Status ist und änderst es in einen anderen Status, damit kein anderer Task das anfassen kann.
Das heißt, es ist.
Direkt am Anfang?
Ja, das ist das allererste, was du machst, bevor du irgendwas anderes machst.
Auf änderst du es?
Auf in Processing oder sowas, oder?
Ja, genau.
Also es kommt darauf an, je nachdem, was du halt für Status hast, es kann ja sein, dass du durch mehrere Stufen durch musst.
Genau, also ich meine, du quasi änderst das nicht direkt in den nächsten, sondern in den Termin.
Sondern du änderst es in einen, der sagt, dass es gerade bearbeitet wird, auf eine bestimmte Art und Weise und dass kein anderer dieses gerade bearbeiten darf.
Und dann machst du deine Verarbeitung darauf und wenn die fehlschlägt, dann machst du es rückgängig und gehst zurück auf den vorherigen Status, weil dann kannst du nämlich einen Retry machen.
Wenn die funktioniert, dann stellst du auf den nächsten Status, sodass der nächste Prozessschritt gewinnen kann.
In der einfachsten Stufe ist es ja, du hast einen, der ist pending, dann hast du Processing und dann hast du dann.
Aber du kannst natürlich diesen Aufbau natürlich X-Stufen haben.
Du kannst ja fünf verschiedene Verarbeitungsschritte oder hundert verschiedene oder dann auch verzweigt haben.
Und das Wichtige ist aber, dass du tatsächlich dieses Statusfeld hast, eins, was Warte auf Verarbeitung heißt und eins, das heißt, wird verarbeitet.
Und dann kannst du sicher gehen, dass du den nicht doppelt verarbeitest.
Wenn du das nämlich das erste machst, das erste, was du machst, du holst dir den aus der Datenbank mit der Datenbanktransaktion, mit einem Select for Update.
Das Select for Update und genau das, ja.
Genau, das Select for Update sorgt genau dafür, dass wenn du den rausholst aus der Datenbank mit dem Status und der ID, das ist sozusagen der kritische Filter, du suchst nach der ID und nach dem Status und dann kriegst du von der Datenbank eben genau einen oder keinen.
Wenn du keinen kriegst, sagst du, gut, dann hattest du wohl schon jemand anders gemacht oder der ist schon fertig oder was auch immer.
Und wenn du einen kriegst, machst du weiter.
Und so schützt du dich quasi davor, dass du diese Race Conditions in die Datenbank reinträgst.
Dass du sagst, okay, der verarbeitet sowas und derweil verarbeitet jemand anderes auch noch irgendwas.
Und er hat das gestern Idem Potency genannt, also Idempotenz, meiner Meinung nach nicht hundertprozentig genannt.
Du darfst es ja nicht ein paar Mal ausführen.
Ja, weil Idempotenz eigentlich bedeutet, wenn du es mehrmals ausführst, hast das gleiche Ergebnis.
So ein bisschen der Outcome ist das gleiche.
Du hast zwar nicht Begriffe dafür.
Korrekte Idem-Potenz.
Naja, der korrekte Begriff wäre hier irgendwie Locking oder sowas.
Dass du sagst, du hast einen Lock da drauf und das machst, hast du so eingerichtet, dass es wirklich nur einer kommt.
Wie gesagt, dieser Talk war für mich hauptsächlich Bestätigung dessen, dass das, was ich mir ausgedacht habe, nicht ganz verrückt ist.
Das ist ja ungeheuer viel wichtig, ungeheuer viel wert.
Dass du nicht so, ja, man baut sich ja oft so Sachen und dann kommt man auf irgendwelche Lösungen und irgendwann findet man raus, das ist absoluter Quatsch.
Ja, ja.
Oh, ich weiß nicht, was ist nicht?
Bei mir passiert es ständig.
Und jetzt mal das andere Erlebnis zu haben, es ist nicht ganz Quatsch, was du dir ausgedacht hast.
Schön.
Ja, genau, genau.
Aber ja, Celery immer so ein bisschen.
Aber der macht ja dann auch so Dinge mit Workflows und keine Ahnung.
Das ist kompliziert.
Ich denke so, ha, lieber nicht, sowas macht man das nicht.
Wie ist denn jetzt der Stand mit den Django-Tasts?
Die sollten doch jetzt langsam machen.
Ja, ist aber noch nicht.
Die kommen auch irgendwann.
Kommt jetzt dann vielleicht demnächst.
Aber ich glaube, es geht ja auch vor allem nur ums Interface erstmal.
Es gibt ja dieses Package, wo das jetzt erstmal quasi so eine Art, ich glaube, die Datenbank-Tasks als Primär-Ding implementiert werden und in Django Core soll tatsächlich nur der Dummy-Taskrunner, den man dann für Tests nutzen kann und das Interface.
Und diese Idee mit diesen Interfaces finde ich super spannend.
Es gibt ja jetzt auch starke Überlegungen, die ganze Authentifizierung bei Django, was ja auch oft kritisiert wird, dass im User-Model ein sehr Western-Centric Vorname-Nachname-Konzept, das passt oft nicht in vielen Use Cases oder auch anderen Kulturen.
Dann viele, es wird dein Username standardmäßig genutzt, du kannst das irgendwie opt-outen, es gibt so Packages, E-Mail-Adresse ist nicht unique, also ganz viele Dinge und dass halt nicht die richtige Lösung wäre zu sagen, wir ändern das jetzt oder wir bauen jetzt was Neues dazu, sondern dass man das einfach auch Plug-in-Play macht, wie halt auch die Datenbankanbindung Plug-in-Plays, wie die Caches Plug-in-Play sind, wie mehr oder weniger eigentlich alles Plug-in-Plays und da ein Authentifizierungssystem zu haben, wäre natürlich super.
Und ich glaube, die auf diesem gleichen Konzept basiert auch dieses Tasks.
Das ist im Endeffekt das Django Core, im Endeffekt mit jedem kompatiblen Taskrunner oder Task, ist es Task Runner, ich weiß es nicht genau, was die dann.
Background Task, äh, Backend, was man sagt.
Ja, Backend, genau.
Task-Backend dann kommunizieren kann.
Wenn man dann sagt, ich möchte gerne eins mit Salary, dann baust du dir eins, wenn du sagst, ich mir reich die Datenbank, dann baust du dir dafür eins oder nimmst das, was da ist.
Und das, äh, ja, ich warte da auch schon sehnsüchtig drauf.
Wir können auch noch kurz vorgreifen auf einen der Lightning Talks, weil da war nochmal der Manda, der auch über die Python Mystery gesprochen hat und hat mit so ein kleines bisschen Zorn gesagt hier, Celery, das ist alles Mist und es viel zu viel Aufwand und deshalb habe ich in mein eigenes geschrieben.
Und das Interessante daran war, dass er das gleiche Interface benutzt hat, wie das von Celary.
Also jetzt nicht das Django Tasks Interface, sondern das von Celary.
Das heißt, es ist ein Drop-in-Replacement und man kann einfach seine Lösung verwenden, wenn man keinen Bock mehr hat auf Celery.
Und wenn es nicht so funktioniert, wie man es möchte, geht mal zurück.
Fand ich auch eine interessante Idee.
Was ich
daran sehr interessant fand, ist, dass wenn man viele nutzen ja, also Celery kann ja nicht mit der Datenbank als Broker sprechen, aus Gründen, die niemand so genau weiß.
Ja, aber es gibt so ein Interface dafür oder so.
Ja, aber das wird immer das Rot umrandet und da.
Das heißt, die meisten Leute nutzen halt dann Redis oder Rabbit im Q, irgendein Derivat davon.
Redis ist das bekannteste, viele Leute nutzen Redis und dann gibt es halt diesen Disclaimer auf der Webseite, dass wenn man halt Scheduled, also wenn man quasi Tasks in die Zukunft plant, dass es da mit Redis-Issues gibt.
Das ist da seit, also wir, uns ist das glaube ich 2018 auf die Nase gefallen.
Und unser, also wir haben ja immer gesagt, okay, dann nutzt man RedimQ, das war kein Problem, aber im Endeffekt haben wir auch dann einfach angefangen, wir planen einfach keine Tasks mehr in die Zukunft, weil du kannst ja einfach quasi die schedulen lassen.
Du kannst ja einen Scheduler verwenden, du kannst andere Sachen.
Also wir haben das wirklich mehr oder weniger gut ausgebaut bekommen, kein Problem mehr, Kuh vom Eis.
Und dann meinte er dann in einem Lightning Talk, da meinte er so, ja, ja, ihr denkt, ihr nutzt die nicht.
Aber in dem Moment, wo ein Retry kommt, nutze die plötzlich schon.
Und das war mir nicht bewusst und das ist dann so ein, oh, dann sollte ich vielleicht wirklich kein Redis zusammen mit Salary verwenden.
Ja, Aivas Calvans ist der Name.
Ja, ja, das ist mal gesagt.
Ich verstehe auch nicht so genau, warum mit dem Scheduling, das funktioniert immer nicht so, wie man das richtig will.
Und das Package heißt übrigens Django-Task-Q, also wie der Buchstabe.
Das heißt, irgendwer mal Spaß, da hat es auf die Special.
Es gibt leider so ein bisschen für viele Django-Task-Sachen.
Da kann man ja so gleich in den Shownotes.
Ich verlinke mir auf jeden Fall.
Genau.
Genau, dann kam so ein bisschen, ging es ein bisschen ins Abendprogramm rein, dann war es schon 17 Uhr und dann kam der Words-Vortrag.
Logs, Shells, Caches und Other Strange Words.
Von einem Dortmunder, das fand ich auch interessant.
Nee, ist ungeheuer weit weg, finde ich.
Ja?
Ja, gut.
Ja.
Hörertreffen in Stuttgart.
Stimmen Sie jetzt dafür ab.
Genau, der Vortrag.
Wir haben uns übrigens ganz kurz zum Hörertreffen, ne?
Schon uns entschieden für es wird.
Er kam ja immer noch um mit dem.
Da ging es dann schon so ein bisschen ins Amtprogramm rein, hat er auch selber gesagt.
War ein sehr unterhaltsamer Vortrag, fand ich.
War sehr schön gemacht, war sehr nett, er hat einfach so ein bisschen über die Etymologie gesprochen und über die lustigen Herkünfte von den Wörtern, die wir benutzen, die aber eigentlich nautischen Ursprungs im 17.
Jahrhundert sind.
Was mich tatsächlich schockiert hat, ist, dass die Story mit dem Bug, also der Motte in dem IBM-Kugel, dass das nicht stimmt, also
dass das nicht die Ursache
davon ist.
Das habe ich schon oft drum erzählt.
Ja, ja.
Das ist auch ein schönes Bild.
Ja.
Aber das musst du mir nochmal erzählen, ich habe den Tag nämlich verpasst.
Warum stimmt das nicht?
Also es gibt diesen Eintrag von dieser Computermitarbeiterin, die die Motte aus dem Gerät gefischt hat.
Ja.
Und dann
in ihrem handgeschriebenen
Logs, also wirklich das, was heute halt auf dem System irgendwie im Hintergrund läuft in einem Buch.
Nazi hat sich die Motte eingeklebt und hat das dann so geschrieben, als, ne, wir haben gerade den ersten Bug gefunden.
Tatsächlich war das aber ironisch gemeint, weil das Wort Bug auf, ich glaube, Edison war es zurückgeht, der geschrieben hat, seinen Ideenfindungsprozess ist, so wenn er eine neue Idee hat, dann kommt das so in einem Schwall heraus und danach kommen wie kleine, wie kleines Umgeziefer, diese ganzen Probleme in der Realität, mit denen sie sich dann auseinandersetzen muss, bevor er dann irgendeine Lösung hat, die er wirklich verkaufen kann oder nicht.
Achso, die kleinen Käfer und dann hat sie gesagt, okay, jetzt haben wir wirklich einen echten Käfer von ja, die Mutter.
Das fand ich aber auch sehr interessant, dieses Zitat, weil das ist ja auch ein Gefühl, was man so kennt.
Dass man einmal so einen Inspirationsschub hat und dann stellt sich da die Realität in den Weg.
Und du
weißt aber eigentlich erst, wenn du diese ganze schmutzige Arbeit gemacht hast, ob es ein Erfolg oder ein Misserfolg ist.
Die Idee
selber kannst du das nicht ansehen.
Außer du kennst jemanden, der den Weg schon gegangen ist und kannst ihn fragen.
Ja, aber das ist keine neue Idee.
So findest du die Glühbirne nichts.
Gut, und danach gab es natürlich noch Lightning Talks.
Lightning Talks sind immer super, finde ich großartig.
Da ist immer eine schöne Auswahl.
Und das war auch gestern so.
Apropos Lightning Talks, ich glaube, es gibt heute interessante Lightning Talks.
Du machst ein bisschen spoilern.
Ich weiß nur von einem Lightning Talk, den es heute gibt, weil ich habe mich angemeldet.
Unvorsichtigerweise zu einem Lightning Talk.
Und ich werde in fünf Minuten darüber sprechen, wie man in fünf Minuten einschlafen kann.
Und wie man das hinkriegt, in fünf Minuten einzuschlafen.
Ja, also wenn ihr dran seid, dann habt ihr es noch nicht geschafft.
Ich habe ja heute Abend dann fünf Minuten Zeit.
Mal schauen, wie viele, bei wie vielen es klappt.
Okay.
Und Ronny, du wolltest auch was über deinen Lightning Talk erzählen?
Genau, ich hatte eigentlich vor, mich gestern schon auch für einen Lightning Talk anzumelden.
Ich habe leider gestern ein bisschen geschwächelt, gesundheitsbedingt.
Hab's ja nicht gemacht.
Jetzt habe ich gerade gehört, dass alle Slots schon voll sind.
Von daher werde ich nicht über das Thema reden, aber ich kann es ja hier ganz kurz präsentieren.
Sehr gut.
Nee, morgen ist ja auch schon voll, ich bin gehört.
Auch schon voll, hiile.
Genau, es geht darum, dass ich habe vor einiger Zeit, ich habe da auch einen Blogpost drüber geschrieben, hatte ich den Fall, dass wir so eine Art Django-Devs-Geschichte in so einem großen Monolithen brauchten.
Es hatte zu suchen, jetzt ganz konkret, um Django Migrations aufzuräumen für einen relativ spezifischen Case für ein Projekt mit sehr, sehr langen Deploymentzyklen und so.
Und ja, das aus Gründen nicht funktioniert hat und so wegen The Circle Penancies auflösen, dauert zu lang, etc.
etc.
Auf jeden Fall habe ich dann mich relativ stark dafür eingesetzt und habe da beim Kunden auf so ein paar Hierarchie-Ebenen Hierarchietreppchen rauf und runter gemacht, um die davon zu überzeugen, dass wir das Ding dafür einfach Open Source machen könnten und sie es trotzdem voll zahlen.
Was am Anfang für ein paar gehobene Augenbrauen geführt hat, weil warum Open Source?
Hä, wir zahlen doch nicht.
Warum Sachen verschenken?
Genau.
Und ich habe dann aber nachher tatsächlich einen ganzen Haufen Argumente gefunden, warum das einfach für alle Beteiligten besser ist.
Beispielsweise.
Wenn man endlich eure Fehler finden kann, die dann auch öffentlich verfügbar und einsehbar sind.
Jetzt, ne, vor allem auch, weil wir ansonsten das halt irgendwie den Moniten reingewurschelt hätten und sobald irgendwann mal ein Problem kommt, sowas fasst ja nie wieder einer freiwillig an.
Wenn das jetzt Open Source ist, dann würde ich mich zumindest, solange ich es aktiv maintaine, mich drum kümmern.
Und ich hatte bei zwei Themen, wo ich selber.
Der Diskurs war
also ein Maintaining-Versprechen.
Interessant, ja?
Solange ich mich drum kümmere, zumindest.
Da war die Schwingerplanung noch nicht so weit fortgeschritten.
Wird mich wahrscheinlich irgendjemand auf meine Python-Podcast-Folge von vor zwei, drei
Jahren, wo ich halt
festnageln, wo ich gesagt habe, das muss man immer weiter maintain.
Nein, genau, und
man kann ja auch schlecht maintainen.
Ich maintaine Sachen aber teilweise sehr, sehr, sehr schlecht.
Nein, aber vor allem, dass das Schöne an der Geschichte ist, nachdem ich das, also nachdem ich das gemacht habe, einen Artikel drüber geschrieben habe und es halt wirklich auch im Endeffekt eine wirkliche Win-Win-Situation war, weil ja auch wirklich die Inkoppelung auch dann da war, man gar nicht in die Verlegenheit kam, irgendwas projektspezifisch zu machen, hatte ich dann irgendwann plötzlich ein Issue von einer scheinbar sehr, sehr kompetenten Entwicklerin, die geschrieben hat, dass sie folgende zwei Probleme identifiziert hat.
Und das eine hatte ich so literally as to do im Code, weil ich wusste, dass ich das eigentlich noch fixen muss, aber ich brauchte es halt für ein Case gerade nicht, darum habe ich es dann offen gelassen.
Dann hat sie mich gefragt, ob sie das lösen darf und hat dann zwei absolut perfekte Merch Requests, wo ich wirklich absolut oder fast nichts dran aussetzen konnte, delivered, die einfach funktioniert haben, alles durchgetestet.
Und das sind halt Sachen, die hätten die ansonsten halt niemals da reinbekommen.
Und genau, ansonsten, ich nutze das natürlich auch für meine Projekte und das ist eine sehr schöne Success-Story.
Und ich glaube, wenn das mehr Leute im Kopf haben, dass das geht, dann könnte man sehr, sehr viel mehr in Open Source einfach leveragen über Kundengeld, wenn man es halt einfach im Kopf hat.
Und das wolltest du quasi als Success Story verkaufen und ein bisschen Werbung zu.
Was war das genau?
Worum ging es da?
Also ich hab, du hast gesagt, Deployment Zeugs bei Django, das.
Also genau, das Package heißt Django Migration Zero.
Es gibt leider, ich habe auch eine Sache, wenn man Packages erstellt, checkt vorher mal, was es für Packages gibt, die ähnlich heißen.
Ups.
Es gibt nämlich Mix Zero und Migration Zero Django und ich glaube Migration Zero ohne Django.
Ja, meinst du, ich habe einen Artikel geschrieben, ich habe im Blogpost das verlinkt und noch einen Artikel drüber geschrieben.
Das heißt, Google packt mich jetzt auf Platz 1, glaube ich.
Aber genau, also es geht einfach darum, dass wenn man, wir bei uns nutzen aus historischen Gründen, wie du vorhin auch meintest, man hat mal so eine Lösung im Kopf und dann nutzt man die immer weiter.
Wir haben, um quasi Object Ownership zu haben, haben wir quasi in so einer Toolbox-Package, wo so kleine Dinge, die sich nicht als eigenes Package lohnen, haben wir quasi so dieses Created By, Lust, Modified By und das zerzielt halt auf den User, was dazu halt aber führt, dass wir sehr, sehr viele Circular Dependencies haben, wenn wir ein Custom-User-Model haben, was wir aus historischen Gründen, weil früher war das alles sehr mühsam mit Django, mit Aussie immer mit auch Model switchen und haben wir meistens uns für ein Custom Model entschieden, was wir heute nicht mehr tun, aber es ist bald ein älteres Projekt.
Und das heißt, du sehr, sehr, sehr, sehr viele Circular Dependencies und wenn du squashen möchtest, musst du die, also das dauert, weiß ich nicht, Tage, glaube ich, hätte das gedauert zu lösen, für den Effekt, dass ich weiß, welche Migrations mal da waren, aber das ist halt kein Package, das ist ein deployedes System.
Also was auf ein Produktivsystem angekommen ist, da ist Ende.
So, ich muss nicht wissen, was danach passiert ist, was davor passiert ist.
Das heißt, es ist einfach determiniert und ich kann mir halt einfach auch, was Migration Zero im Endeffekt ist, ist, du gehst halt einfach hin und löscht alles.
So, und startest halt neu.
Weil das, das, das ist.
Haben wir alle schon ausgemacht.
Create Migrations lustigerweise nicht das Problem hat, was Squashing hat, mit, das kriegt es einfach hin.
Ich weiß nicht wie, aber es kriegt es hin.
Und genau, von daher ist das halt für, wenn man einfach eine Applikation hat und regelmäßig aufräumen möchte.
Der Trick ist halt, dass ich im Endeffekt.
Du hast die Datenbank einmal so gezogen, dass der Stand stimmt und dann schmeißt du alle Migrations weg und machst neue Migrations hin.
Genau, und du kannst halt in ganz, ganz viele Edge-Cases kommen, die nicht so allzu wahrscheinlich sind, aber wenn du halt ein Produktionssystem hast mit Uptime und sowas, möchte man halt einfach nicht sich solche Dinge einbauen.
Das heißt, du musst halt auch gucken, dass für die Django Migration Table im Endeffekt der Apply-Cache von Django muss man halt auch aufräumen.
Und damit man halt, weil niemand gerne auf der Produktionsdatenbank herumfudelt, habe ich quasi ein Skript geschrieben, das das für einen macht.
Und du kannst es von Django-Adem quasi an- und ausstellen.
Also sagst, okay, ich weiß, es kommt ein Deployment, das nächste Deployment, das ist, mach den Haken an, dann macht der das quasi für einen selber.
Das heißt, du musst nicht mehr auf der Datenbank rumfudeln, du musst im Endeffekt einfach nur noch das tun, was du gerne machst.
Irgendwas im Code ändern, committest das und der Rest.
Passiert dann automatisch und genau.
Das ist sehr, ich finde das für den Use Case sehr convenient.
Ja, cool,
coole Sache.
Nice.
Aber habe ich das richtig rausgehört?
Ihr nehmt kein Custom User Model mehr.
Wir versuchen eher über diesen User-Profile-Ansatz zu gehen.
Also das Problem ist, dass ich glaube, Django lädt sehr, sehr, sehr, sehr, sehr, sehr stark dazu ein, dass man so gewisse zentrale Models mit immer mehr bädt und dass man halt nicht wirklich versucht, Domänen zu schneiden.
Ich meine, Foreign Keys, so enorm praktisch die sind, ist halt auch, du bist halt einfach in irgendeiner Funktion plötzlich drei Domänen irgendwo weiter und hast dann plötzlich irgendwelche Daten dir gefischt, weil es geht halt.
Und von daher versuchen wir jetzt in den neuen Projekten eher über Profile zu gehen.
Aber Profile
ist bei euch ein eigenes Modell, eine eigene Tabelle, überzeugst du?
Genau, also wir sagen quasi
alle, also der
Django-User ist nur für die Authentifizierung da.
Also wir nutzen im besten Fall auch nicht den Namen oder E-Mail, also eine E-Mail-Adresse logischerweise schon, aber nicht den Namen.
Und dann gibt es zum Beispiel dann irgendwie ein Account-Profil, wo dann der Name drinsteht, dann vielleicht die Adresse.
Dann was?
Das ist vielleicht gerade kein Beispiel, wenn man zum Beispiel, wenn ihr sagt, ich habe irgendwelche Konfigurationen, die ich machen kann in meiner Applikation, gibt es vielleicht ein User-Konfigurationsprofil und versuche das aufzuteilen und dann die verschiedenen kleinen Models in ihren Domainen zu haben, was ja auch dazu führt, dass du, wenn du zum Beispiel den User immer weiter aufbläst, so teilweise hast du dann ja 50, 60 Felder in einer hinreichenden großen Applikation, ist ja keine Seltenheit, die Daten werden auch immer gefetcht.
Und die wenigsten Leute in Django machen ja auch, dass sie wirklich dann per Select sich nur die Felder holen, die sie brauchen, sondern eher so, ja, gib mir mal alles.
Das erzeugt auch wohl vor allem gegeben der Last, aber auch immer einen relativ großen Overhead.
Plus ist natürlich auch für den Däxen Junior, der ins Projekt kommt, der muss halt 50 Felder verstehen und nicht nur drei.
Das mit den Daten habe ich noch nicht drüber nachgedacht, aber ich habe jetzt tatsächlich User-Profile an ein Profile Jason-Feel gehängt.
Ja, also ich finde JSON-Fields sind ein sehr zweischneidiges Schwert.
Das ist immer so ein bisschen, die führen so ein bisschen die relationale Datenmark ad absurdum.
Fanche Dinge sind die super.
Ja, für solche Sachen ein Profil möchte ich, dass es nicht filtern, also das sind nicht so Filter-Ribbles, deswegen ist es egal.
Aber ich versuche, also ich sage mal so, ich versuche die, ich nutze die, aber ich versuche da dreimal drüber nach, ob ich es wirklich nutzen möchte.
Und wenn ich zum Beispiel so auf die Profilkonfiguration habe, weiß ich nicht die Farbe und die Sprache und keine Ahnung was, das kann ich ja relational speichern, dann versuche ich es auch zu tun.
Ich bin tatsächlich gerade in die andere Richtung unterwegs zum Thema User Model.
Ich bin jetzt eher wieder dazu übergangen, Custom User Models zu machen.
Aber nicht, um da Felder hinzuzufügen, sondern eben genau, um Felder wegzuschneiden.
Weil ich kein First Name brauche, ich brauche kein Last Name, ich brauche kein Programm.
Ich habe auch alles geschrieben.
Username nur E-Mail gemacht.
Ja, genau, einfach nur E-Mail und Passwort und das ist eigentlich für die meisten Sachen reicht das ja schon aus.
Aber dann spricht ja tatsächlich meinem eigentlich gar nicht.
Ja, genau.
Das ist ja eigentlich das gleiche.
Ja.
Vielleicht sogar noch ein logischer weiterer Schritt.
Ja, aber halt mit Aufwand verbunden.
Und das ist dann in meinem Projekt-Template drin und dann habe ich es einmal gemacht und dann ist es fertig.
Ja, das ist auch sowas, dass man baut sich ja dann irgendwie so eine Sammlung an so eine Schatzkiste an Lösungen auf.
Die benutzt man dann schon immer wieder.
Und wenn die verloren geht, dann bin ich wieder ein Jungbo-Anfänger.
Dann kann ich einmal von einem.
Darum haben
wir damals vor allem
angefahren, die ganzen Sachen in ein Package zu packen.
Das ist zwar nicht der Weg, wie Packages sein, die sollen ja eigentlich Single-Purpose und dass du einem eine Sache hast.
Aber es gibt so viele Kleinigkeiten auch für ein Admin, wo man sagt, so ja, ich will das jetzt nicht jedes Mal neu googeln, wie ich jetzt dieses eine Read-only-Dingsbums da irgendwie machen kann oder sowas.
Oder diesen einen Sonderfall mit, weiß ich nicht was.
Das ist schon praktisch, wenn man das da reingießen kann.
Ja, man hat sich halt ein kleines
Karätes Maiglökchen da gemacht, hat noch ein bisschen gehegt und gepflegt und ordentlich aufgezogen und dann noch die Ecken und Kanten ein bisschen richtig gestutzt, dass das da genauso aussieht wie man.
Genau.
Also wir zum Beispiel, also ich finde das zum Beispiel super, dieses Toolbox-Package, das wir haben.
Also das nutzen wir in den Projekten.
Da sind natürlich auch viele Sachen drin, die Leute einfach nicht brauchen.
Aber ich meine, im
Endeffekt, es ist halt, ja, also ich räume da auch regelmäßig auf.
Also einfach, wenn ich dann sage, okay, jetzt bin ich der Zeitpunkt gekommen, wo das nicht mehr relevant ist oder habe einfach Sachen aktiv rausgezogen.
Also das PolyExpress Package, von dem ich vorhin am Anfang gesprochen habe, das war auch mal Teil davon.
Habe ich aber gesagt, ja, aber das ist sowas von Single Purpose, also das macht keinen Sinn, das da mit reinzufrudeln.
Das kann man gut rausziehen.
Genau.
Cool.
Dann sind wir mit gestern durch mit den Nachricht, dann kommen wir nach heute.
Heute hat der Tag angefangen.
Er hat sehr früh angefangen.
Einer, ihr habt so früh, weil das dann auch nach unserer Zeit 9 Uhr nach lokaler.
Mein Jetlag ist schon vorbei.
Ich fand es jedenfalls interessant.
Es war ja, also ich meine, es war der Talk für die Django Software Foundation, die Versammlung der offizielle 20.
Geburtstag.
Ja, war ja gar kein Talk, sondern es war das Django Software Foundation Board Meeting.
Ja.
Das jährliche Boardmeeting, das erste jährliche Boardmeeting.
Also weiß noch nicht, ob man davon jährlich kommt.
Gleichzeitig im Geburtstagsfeier 20 Jahre Django, es gab auch Kuchen.
Genau, es gab Kuchen, ja.
Das war sehr schön.
Aber es war halt heute früh um 8 Uhr und mir ist durchaus aufgefallen, dass dann so um 8.10 Uhr noch ein paar Leute gekommen sind.
Um 8.15 Uhr oder um 8.20 Uhr.
Oder um 8.30 Uhr wie ich.
Es scheint tatsächlich ganz einfach zu sein, so früh aufzustehen.
Und für mit Kindern ist es eigentlich so.
Nicht kann man doch so mit die
Busse fahren, so ein Mittel von Wanderer.
Ja, okay, gut, das ist natürlich ein bisschen.
Selbst ein eigenes Herr Bin-Bisus.
Tja, wir sind ja alle hier im
Hotel, da ist es natürlich einfach.
Ja.
Müssen wir runterlaufen.
Ich habe jemanden gesehen, der mit Badelatschen die ganze Zeit.
Da dachte ich mir so, oh, warum bin ich da nicht drauf gekommen?
Ja, ich hab mich auch nicht getan.
Ich wollte eigentlich gerade eben nochmal ins Stimmen und Steam, aber dann muss ich mit Bademantel an der Konferenz vorbei und kurz winken, ha!
Mit Bademantel zur Konferenz gehen.
Das habe ich mir auch bekommen.
Solange der
Bademantel zu ist, doch alles so gut.
Das ist auch eine Frage.
Also ich passe da immerhin rein, ich habe ja nämlich meinen eigenen Bademantel deswegen.
Das haben wahrscheinlich auch nicht so viele, aber.
Okay, also das Jungle Software von Dational Board Meeting, das war.
Ich bin da hingegangen, weil ich das mal sehen wollte.
Ich weiß, dass ich da nichts beitragen kann.
Ich weiß, dass ich diese Verantwortung nicht tragen kann, weil ich nicht genügend Zeit habe.
Und was hast du gesehen?
Es war interessant, die Diskussionskultur war interessant.
Die Menschen, die sich daran beteiligen, ich meine, viele von den Namen kennt man, wenn man so ein bisschen in der Szene ist.
Aber es war trotzdem einfach mal interessant zu sehen, wie die so.
Wie viel Zeit man mit so Dingen verbringen kann.
Richtig.
Auch wie viele Metadinge einfach passieren müssen und wenn sie nicht passieren, wie viele negative Konsequenzen das hat.
Und wie viele Kommentare es gibt zu allem.
Ja, dann muss man doch mal reden, jeder darf auch was dazu sagen und dann wird dem auch zugehört und dann.
Genau.
Also genau.
Sehr corporate.
Und dann gab es Kuchen, das war sehr schön.
Hat sich gelohnt, früher aufzustehlen und hinzugehen.
Ja.
Gut, dann gab es den Einführungsvortrag des heutigen Tages so für die breite Masse, sag ich mal, im Mainstream.
Oh, im Mainstream?
Im Main Hall.
Ne, das heißt ja Main Hall, ich meine.
Gab's den?
Habe ich den verpasst?
Nein, da war es bei Most Bizarre Software Bugs in History.
Achso, achso, ja, das ist.
Ja, okay, klar.
War eine schöne schöne Aufstellung.
Achso, hat der Jochen den Lightning Talk vom Johannes vorher schon gehört?
Ich habe ihm das vorher kurz gezeigt.
Nee, das war nur der Vulkanier Mindcraft.
Genau, das war auch eine sehr schöne, war sehr unterhaltsam, dieser Vortrag.
War erstaunlich lang.
Sie hat viele Sachen gesagt.
Viel von den Geschichten.
Kennt man ja schon so ein bisschen, ja, man hat es ja schon mal gehört.
Und Lion Air Flight 110 und ähm.
Ich hab gar nicht mehr die Geschichten alle notiert, ich habe nur notiert, wie die Geschichten heißen.
Ja, das mit der
Mars-Mission mit dem metrischen System.
Ja, guck mal.
Vielleicht gehen wir nochmal kurz auf ein.
Also ein Bugger ist natürlich ein Flugzeug abgestürzt, nicht so gut, weil.
Nee, es sind zwei sogar, es sind zwei abgestürzt.
Boing, was passiert ist.
So ein System eingebaut hat, dass die Nase immer korrigieren sollte und dann ist der Sensor ausgefallen.
Sie hatten nur einen eingebaut und dann.
Und die Piloten wussten nichts davon.
Bei dem zweiten Flug, der war sogar noch ein bisschen tragischer, weil da wussten die Piloten davon.
Haben sie nicht abgesteckt gekriegt.
Haben sie nicht abgesteckt gekriegt und vor allem dieses System ist gekoppelt an den Steuerknüppel.
Das heißt, die haben versucht, an dem Steuerknüpfel zu ziehen und das System hat dagegen gedrückt und irgendwann konnten die nicht mehr.
Und das finde ich noch viel tragischer, ja, wenn du halt gegen die Maschine kämpfen musst und die Maschine in dem Moment will dich umbringen.
Wie ist es gesagt, und dann gewinnt es auch.
Das ist hart.
Das ist echt hart.
Und dann knapp.
Und dann, genau, nachdem diese beiden, nachdem diese beiden Flugzeuge abgestürzt waren, sind ja auch die gesamte Flotte einfach stillgelegt worden mal für den Moment, bis die einmal eine neue Zertifikation durch war.
Ja, Didi, ja.
Also es war eine wirklich schöne Aufstellung von Sachen.
Auf der Mars-Mission ist vielleicht auch noch interessant.
Ah ja, Mars-Mission, ja.
Ja, weil es dann einen kleinen Bug gehabt zwischen Umrechnung, zwischen metrischem und kleinere.
Wer ist nochmal das andere System?
Genau, das eine.
Imperialismus.
Das eine Team hat halt das eine Team hat halt in Zoll gerechnet und das andere hat in Millimetern gerechnet.
Empire Strikes Back.
Was ich total ironisch finde, wirklich, wenn man mal in den USA war, da wird ja dieses Independence Day und diese Unabhängigkeit von England wirklich ganz, ganz, ganz, ganz hoch gehalten und keine Gelegenheit, nicht jedes Schiff und jeden Soldaten nochmal hervorzuheben, wie besonders das war, gegen Engler gewonnen zu haben, aber da mit Händen und Füßen am imperialen System bei den Einheiten festzuhalten.
Am Ende gewinnt der König doch.
Ja, das war auch eine tragische Sache, dieser Mars Reconnaissance Orbiter war das, glaube ich.
Wo einfach die Positionierung nicht gestimmt hat.
Das heißt, er wollte um den Mars kreisen, aber er hat ihn getroffen.
Klabumm.
Andererseits, ich habe es auch zum Jochen schon in dem Vortrag gesagt, ist auch so ein gewisser Power-Move, ja, von der Erde, dass wir da hier Jahre und Millionen reinstecken und dann einfach zack.
Verglüht im Orbit ein.
Ja, und dann die anderen Geschichten, da gibt es ja viele so Geschichten.
Was ich tatsächlich praktisch, also ich meine,
die meisten Leute werden keine Software für Flugzeuge schreiben oder auch den Mars nicht mit irgendwas beschießen, aber was tatsächlich viel im Alltag irgendwie betrifft und das ist tatsächlich auch immer eine sehr hübsche Fehler, also dass Leute Excel-Sheets halt für alles mögliche verwenden.
Und dann da halt diese ganzen normalen Standard-Software-Engineering Practices, die man halt so hat, die ja nur vor dem gröbsten irgendwie bewahren, die gibt's da halt nicht.
Du kannst auch Excel anders nachbauen.
Bitte?
Kann das dann
auch nachbauen, dass du den Excel-Sheets?
Ja, hast du schon mal gesehen, dass jemand Excel-Sheets in einen quasi.
Bitte keine Unitests
auf euren Excel-Shield.
Oder Unitests
oder irgendwie ein Repository eincheckt und das gibt es alles irgendwie nicht so richtig.
Ja, ich hab.
Nee, das geht alles über 30 Jahre zwei Jahre nachgebaut.
Das war ganz tolle Erfahrung.
Achso, du hast es mal nachgebaut.
Oh, gehört.
Genau.
Das kann ja dann auch, also sie hat ja da auch so ein paar Sachen erwähnt, die einfach richtig schlimme Folgen haben.
Das JP Morgan hat halt eine von den Berechnungen, haben sie Hups addiert, statt zu mitteln.
Und dann haben sie ihre Risikobewertung einfach um Faktor 2 falsch gehabt und Milliarden an Dollar verloren.
Ja, gut.
Als Softentwickler sagt man, selber schuld.
Hättet ihr immer auf uns gehört.
Passiert mir jedes zweite Wochenende.
Ja, 6 Milliarden unter Freunden kommen.
Ja, genau.
Also es war wirklich eine schöne Zusammenstellung, war sehr unterhaltsam, war ein guter Angst.
Und auch einen sehr guten Vortragsstil.
Ja.
Ja, war wirklich sehr angenehm.
Ja, was kommst du da noch?
Danach.
Oh ja, das war das war cool.
Danach war so ein bisschen, für mich ein bisschen bisher das Highlight des Tages.
Das Highlight der Woche bisher.
Haki Benita.
Genau.
How to get foreign keys.
Horribly wrong.
Ja, das müsste man jetzt erzählen, weil ich bin nämlich in der Zeit rübergegangen zu dem anderen Workshop.
Und ja, hab dann aber nicht so wirklich zugehört, sondern gearbeitet.
Aber deswegen kann ich zu dem Workshop erzählen, aber den Top von Haki Benita hätte ich gerne noch mehr verstanden, wie man denn Foreign Keys richtig macht.
Indizes Sets oder was hat er gesagt?
Yeah.
Aber also die Sache an Haki Benita ist, der ist ein DBA, ein DBA Database-Admin, der seit 20 Jahren im Geschäft ist, der kennt alle Tricks.
Und er
hat einen sehr unterhaltsamen Vortragsstil, das war wirklich.
Ja, und auch das Publikum mit einbezogen und Fragen und dann auf Leute gezeigt und so.
Also es ist großartig.
Aber er hat so ganz harmlos angefangen und hat gesagt, ja, was fällt euch da auf?
Und dann kam natürlich so, ja, da muss man ein Index machen.
Und er hat gesagt, ja, aber.
Und dann hat er das gemacht und hat so ein bisschen da die Sachen erzählt.
Und er hat gesagt, was fällt euch denn jetzt auf?
Und dann ist er noch eine Ebene runtergegangen und dann haben schon weniger Kommentare und hat gesagt, was fällt euch denn jetzt auf?
Also er ist einfach ganz harmlos angefangen und dann so tief runtergegangen wieder.
Ja, aber dann ist das Publikum.
Also er das
aufgehört hat, hat das Publikum an seiner Stelle weitergemacht und hat ihm gesagt, wo ist noch nicht.
Und bei seinem Fazit war dann so, okay, das mit den Migrationen sollte man einfach lassen.
Das ist keine gute Idee, das ist irgendwie nicht machen.
Ja, also es ist wirklich, es ist halt problematisch, je genauer man hinguckt, desto mehr Probleme sieht man da auch.
Sie natürlich aber auch nie nur nicht in allen Cases wirklich rein.
Nein, vorher wieder so eintaucht.
Es ist immer so, die sind erstmal kurz zum Erklären.
Also, dass das ein interessanter Talk war, haben wir jetzt verstanden, aber worum ging es denn jetzt eigentlich?
Also es, bist du?
Nee, sprich du aber nicht.
Also es geht im Endeffekt ging es darum, es war im Endeffekt ein Standardmodel, also Django Model, jetzt mehr oder weniger, was man halt so kennt.
Und die und dann ging es halt darum, so quasi, was kann man daran verbessern.
Hat sich halt Expedital Forum gesehen.
Was ist gefährlich auch?
Genau, oder was könnte gefährlich sein?
Natürlich immer mit dem Hintergedanken, wenn man da jetzt eine Tabelle mit 50 Einträgen hat oder auch 500.000, ist das wahrscheinlich alles relativ egal oder kein Hochverfügbarkeitssystem, aber halt, was für Systeme kann, was kann man halt theoretisch kaputt machen, ohne es zu wissen.
Und dann hat er sich halt quasi dann darüber rausgehangelt, wie sieht es aus, mit wenn ich diesen Index setze, was ist mit automatisch gesetzten Indizes, kann ich die wegnehmen?
Ja, genau, und wie weit kann man da gehen?
Genau.
Was kann
man alles kaputt machen?
Was kann einem alles implizit auf die Füße fallen?
Genau.
Und dann auch viel über Migrations, Migration-Anordnungen, was man damit noch anders machen kann, also indem man die einfach auseinanderzieht, atomare Transaktion, also Datenbank, atomare Transaktionen, genau Reihenfolge und da halt immer weiter runter.
Und das halt in einem sehr, sehr energetischen, interaktiven Weg, um auch dieses Thema, dass man auch perfekt ultra trocken irgendwie runterbeten könnte.
Also das ist tatsächlich
einer von
den Talks, die ich mir auf die Liste geschrieben habe, für die muss ich später nochmal nachschauen.
Also was konkrete Dinge drin waren, wie zum Beispiel ist sowas wie, du hast halt ein Foreign Key auf dein User-Modell als Created Add oder sowas an irgendeinem Modell dran.
Und wenn du jetzt sagst, so okay, das wird jetzt schon anwendig ganz groß, äh, relativ groß, ich mach das, es wird eh nie benutzt und dann nimmst du den Index weg und dann löscht irgendein automatischer Job ab und zu mal User und leg dann deine Datenbank lahm, weil, naja, es ist kein Index mehr auf dem Ding und dann macht das halt ein Tablescan bei jedem User, der gelöscht werden soll.
Und wenn das viele sind, dann, naja, es ist halt.
Ja, auch wenn es einmal auftritt ist, wenn du irgendwo eine Tabelle mit Millionen rein hast.
Wenn du bei Instagram mit 500 Millionen Nutzen anscheinend noch ein bisschen.
Ja, genau, die müssen da schon aufpassen.
Das hat er am Ende auch gesagt, ja.
Viele von den Sachen sind halt jetzt rausgesucht als Probleme für einen Vortrag, sonst kannst du nichts zeigen.
So für den Hausgebrauch für die, wenn du 10.000 TPS hast, Transaktionen pro Sekunde, ist das jährlich ein anderes Thema, als wenn du drei Transaktionen pro Sekunde hast.
Also ich glaube, eine von den Learnings war, dass er quasi die Nutzer aware gemacht hat, dass Django sehr viele Dinge einem für einen mitdenkt und dass es halt Cases gibt, wo man das eigentlich, wo man das nicht tun, also wo man Django nicht das.
Also er hat am Anfang die Queries, glaube ich, mit angemacht,
die bei den Queries, dass man sieht, was macht.
Ja, oder dass man
auf jeden Fall immer die Querys sich bei der Migration zum Beispiel, da hatte dann irgendwie eine schöne Stopp-Pandline, die dann ab und zu mal haben, sondern erst immer mal das SQL angucken, bevor man die Migration wirklich ausführt, weil den
wichtigsten Schritt hat er da für mich eigentlich in den Fragen am Ende gesagt.
Dann hat er nämlich gesagt, bei ihnen machen sie es so, dass sie eine GitHub-Action haben, die das SQL, wenn du eine Migration machst, schreib die dir das SQL als Kommentar in deine Review.
Das fand ich auch krass.
Das heißt, du bist gezwungen, dieses SQL anzugucken.
Du kannst gar nicht, du kannst nicht zustimmen, ohne das SQL gesagt zu haben.
Und das fand ich einen super Trick.
Ja, weil das so ein, weil das so
ein, das
ist psychologisch korrekt, ja.
Das ist kein, wir halten dich ab, das zu tun, sondern ein Hier, guck doch mal.
Ja, absolut.
Großartig.
Und was auch noch echt cool war, der hat gesagt, dass sie exzessiv die Django-Checks verwenden, also die System-Check-Frame.
Aber mit eigenen geschriebenen Regeln.
Genau, also erstmal hängt es bei denen in der Pipeline, das geht relativ einfach, das haben wir jetzt auch angefangen einzubauen.
Also das führt auch dazu, dass man da einmal wirklich auch mal guckt, was Django so meldet.
Manche Dinge machen jetzt auch zum Beispiel in einem Pipeline einfach keinen Sinn, manche Einstellungen, aber trotzdem, dass man die da einmal so konstruiert, dass es der Pipeline grün ist, was schon mal super ist, und eigene Checks wirklich zu verwenden, weil das ist, die laufen natürlich in jedem Mal, wenn der Development-Server startet.
Das heißt, wenn man da sehr viele hat oder sehr langsame hat, kann man natürlich die Developer-Experience massiv beeinflussen, negativ.
Muss man ein bisschen aufpassen.
Weil viele Dinge könnte man auch irgendwie in der Linting-Stage machen, vermutlich.
Trotzdem hast du halt Zugriff auf das komplette initialisierte Djungo-Projekt und da kann man, glaube ich, sehr, sehr viele coole Dinge Richtung Code-Qualität machen, weil du halt den Leuten sagst, so, hey, guck mal hier, lieber Mitentwickler, folgendes ist gerade komisch.
Das ist sehr mächtig und das ist auch eine Sache, wo ich mich auch nochmal mehr damit beschäftigen möchte.
Weil ich glaube, dass das wirklich sehr, dass man da nochmal sehr viel rausholen kann.
Wie letztes Jahr beim Vigo bei dem Talk, deine Architektur oder Code-Qualität ist so gut wie dein Tooling, das du hast.
Ohne Tooling degradet alles sofort.
Also waren auf jeden Fall viele coole Sachen drin.
Haki Benita ist immer gut.
Jochen kann ja die Links wieder unten reintun.
Dann der nächste Talk.
Karl Gibson.
War gar kein technischer Talk diesmal.
Nee, er hat ja auch am Anfang so scherzhaft gesagt, nächstes Mal wieder technischer Talk war viel zu anstrengend.
Ja, how we make decisions in Django.
Ja.
Mir fällt es schwer, da jetzt was zu sagen.
Ich habe in der Zeit was gegessen, Kaffee getrunken.
Ja, ich würde auch zu, es ist halt ein schwieriges Thema und ich habe absolut keine Meinung, dass ich
oder keine Ahnung davon.
Ich würde auch sagen, so ja, ja, ich finde
es gut, dass das jemand macht.
Also im Endeffekt, es ging ihm ja, glaube ich, ging ihm ja darum, dass er ich werde darauf angesprochen, ich zu oft im Endeffekt sage.
Ja, wir haben schon
ein Fake-Spiel daraus gemacht, dann
werden wir heute Abend beim Re-Review der Folge nochmal spielen.
Ging ihm darum, dass halt der Prozess, wie über gewisse Dinge abgestimmt wird, also meist im Forum soll er diskutiert werden, dass das sehr, sehr mühsam ist, da kann ich doch einen schönen Bogen spannen zu meinem Eingangsthema.
Ich habe vor einem Jahr sind in den Django Storages, ungefähr vor einem Jahr, glaube ich, sind die Django Django Storages, ist die Settings API leicht verändert worden.
Da gibt es irgendwie statt mehreren Einzelvariablen, gibt es eine Variable.
Da gab es auch eine Warnung und normalerweise kümmere ich mich da mal sofort, Thomas, wir hatten dann einen ganz, ganz merkwürdigen Bug mit dem Sorrel-Tumbnail-Package, irgendwas ganz Wildes, wo nichts mehr funktioniert hat.
Und ich habe dann einfach, ich mach das dann später.
Und dann irgendwann war die Warnung halt weg und ich so, ah, okay, dann.
Ja, perfekt.
Gesetz gelöst, super, besser.
Hat es halt auch nicht ausnahmsweise halt einmal nicht drauf, wie das halt immer so ist.
Das ist dieses Schweizer Käse-Modell, das ist halt genau einmal.
Das kommt ja
nachher auch.
Nee, das kam vorher schon im Baxenvortrag.
Genau in dem einmal, wo man sich ja nicht sofort drum kümmert, wo irgendwas komisches passiert, wo man es halt dann doch irgendwie ein bisschen aufschiebt.
In Kombination mit Django Storages, was wir für S3, also für Datentransfer nach S3 verwenden, war eine Plattform, an der ich gearbeitet habe.
Und genau in dem Zeitfenster, wo wir dann quasi das Django upgedatet haben, wo dann quasi diese Storage war, also dass die Deprecation quasi aktiv wurde, wurden dann halt von den Nutzern hunderte von Dokumenten hochgeladen, was mehr Dokumente wahrscheinlich waren, als insgesamt bis jetzt hochgeladen wurden, weil das halt so ein neues Feature war, das dann live ging.
Und leider hat Django Storage das nicht gemerkt.
Django dachte, das Feld ist nicht mehr da und die Sachen sind alle in Nirvana gelandet.
Das war ärgerlich.
Eine schöne Übertreibung, die du hier wählst.
Ärgerlich.
Ja.
War natürlich auch etwas schwierig, dann den Leuten zu erklären, sorry, bitte alles nochmal.
Teilweise waren die Sachen natürlich auch einfach da, nee, die sind da ja da, die.
Ja, klar, braucht man nicht ja.
So, weg.
Ja, war sehr blöd.
Dann habe ich das ja im Django Forum halt mal angesprochen, hab gehört, hey Leute, es ist so etwas irgendwie dumm gelaufen, kann man nicht was tun.
Und dann hat sich da so eine Diskussion ergeben, dass man ja vielleicht, weil Django ist ja super dokumentiert, so bis Version 1.0 zurück, ob man nicht einfach sagen soll, hey, wir machen irgendein System-Check mal wieder, ein System-Check, wo wir einfach sagen, hey, guck mal, du verwendest hier eine Variable, die sollte es eigentlich nicht mehr geben.
Denk mal drüber nach, ob du die wirklich noch, ob da alles richtig ist bei dir.
Man kann ja System Checks aktiv disablen und so, wenn jetzt jemand der Meinung ist, er braucht jetzt die Login-URL für irgendwas anderes oder ein ganz third-party-Package, will unbedingt die Login, dann nimmt man es halt aus und lebt damit, dass die disabled ist.
Gut, dann ist mehr oder weniger alles agreed worden.
Ich habe einen Pull-Request gemacht, hab mir sehr zum Ärger von manchen Leuten eine initiale Liste von GPT generieren lassen, weil ich dachte, damit ich erstmal was habe zum Testen, ob es überhaupt funktioniert, hab die ja nachher nochmal manuell abgeglichen, trotzdem waren direkt ein paar Leute böse.
Ich habe dann gesagt, hey, chill.
Wir sind noch nicht sagen.
Ronnie, bist du angesprochen?
So, haben das dann gemacht.
Ich habe nochmal quasi alle Changelogs gemacht, wir haben die nochmal verlinkt.
Ich habe nochmal Optimierungsideen, hey, wenn du ein Set verwendest statt einer Liste oder das ist nochmal ein Ticken schneller, weil das läuft ja die ganze Zeit.
Richtig coole Lösung.
Und dann kam halt von einer Person, naja, aber wir haben doch, wir machen doch keine deprecated Sachen im Framework.
Und dann habe ich so, ja, aber die Leute haben doch gesagt, ich bin nicht der Einzige, dem das passiert.
Es hilft halt extrem.
Es macht den Update-Prozess ein bisschen einfacher.
Es gibt aktuell noch nichts, was das tut, weil sonst wäre es mir ja nicht passiert.
Und ich bin ja aware, dann go upgrade das ganze Tooling, das da gibt.
Klingt doch gut.
Nee, machen wir nicht.
Und irgendwie war dann halt so diese eine Gegenstimme gegen halt 10 Leute, 15 Leute, die im PR mitgearbeitet haben, also auch wirklich motiviert mitgearbeitet haben, oder halt auch im Forum sich geäußert haben.
Und irgendwie hat halt diese eine Person das halt dazu gebracht, dass es halt da nicht passiert ist.
Wie der Diskussion von gestern, wer darf denn mergen und wer sagt dann Nein?
Ja, oder auch das, was Karten gesagt hat, dass Konsens gesucht wird.
Genau, das ist ja genau das.
Und ich glaube, dass er hat, also selbst Carlton war ja auch in dem Thread da dabei und da hat er dann auch das durchklingen lassen, was glaube ich teilweise hinter der Motivation dieses Vortrags stand, weil ihn das, glaube ich, auch manchmal einfach frustriert.
Dass es halt dann quasi, ne, alle Leute sagen, okay, das können wir machen, wie dieser schöne Spruch.
Komme ich jetzt drauf?
Safe enough, good enough for now, safe enough to try.
So, im allerschlimmsten Fall muss man halt so einen Security.
Dann baut man den Check halt wieder aus, wenn man merkt, dass es jetzt nach drei Welt nach einem Major Release furchtbar ist und alles doof finden.
Dann ist es halt, hast du ja nicht mehr, so, keine Ahnung.
Und ich glaube, dass das so ein bisschen auch der, einer der Väter von der Gedanken war, weil ich glaube, der erlebt sowas halt sehr, sehr oft.
Und dass halt eine Person die Handbremse quasi, einmal so quasi schöne Stock ins Getriebe, wo mehr oder weniger sich eine coole Dynamik entwickelt hat, wo man dann auch wirklich sagen kann, ey, guck mal, das ist ein, das hilft vor allem, Newbies halt.
Ja, man gibt halt vor allem dem Veto sehr viel Macht.
Man gibt dem, jeder kann sagen nein und dann stimmt's.
Und egal wie viele Leute vorher.
Es ist ja auch ein bisschen gespaltene Meinung zu.
Ja, das ist auch schwierig, aber wenn sowas unterwegs ist, das ist natürlich super frustrierend, ja.
Wenn du schon viel Zeit und viel Arbeit reingesteckt hast und die Frage Bestimmung gekriegt hast, dann sagt einer, ach nö, du.
Also ich bin ganz oft der Meinung, so better asked for forgiveness than for permission.
Ist aber hier ja nicht so.
Das aber genau bei so einem Framework aber vielleicht genau falsch rum ist.
Weil es könnte ja sein, dass ein Flugzeug mit so einem Django läuft.
Und da muss man.
Ja, also.
Es ist auch so, dass man manche Sachen einfach nicht wieder zurücknehmen kann.
Du kannst manche, also es gibt da den Stoppations.
Das sammelt sich an.
Und das ist so ein, deswegen verstehe ich sehr gut, die Leute, die da so die Knüppel zwischen, wenn der das richtig machen, man kann es halt auch missbrauchen und das kann halt ätzend werden und dann politisch werden.
Das kann ein Drüben-Prozess sein.
Genau, und dann erst die Leute losrennen lassen, zwei Jahre Arbeit, halt, ach nee, übrigens doch nicht.
Ist halt ziemlich blöd.
Also ich meine, im Endeffekt haben wir halt genau das gemacht, um auf den Torchad wieder zu kommen, was Carlton halt auch vorgeschlagen hat.
Er sagt, das Ecosystem von Django ist halt im Endeffekt einer der Haupt-USBs.
Ich hab's schon wieder gesagt.
Ich freue mich darauf hingewiesen.
Und dass neue Dinge erstmal in Packages leben sollen und wenn man wirklich das Gefühl hat, dass das unbedingt in Core rein muss und ansonsten ein gut gewartetes Package halt keinen Nachteil zum eigentlichen Django hat.
Vor allem, wie es gibt ja diesen schönen Sprung aus Python, irgendwie Features go to the main library to die.
Also sprich, sobald irgendwas in der Main Library ist, wird einfach nichts mehr daran entwickelt, weil die Zyklen einfach viel zu langsam sind, um von daher gibt es das Django Removals, ganz kurz, noch ein kurz, also wer sich dafür interessiert, das ist sehr, sehr klein und tut nur was auf dem Development-Server, kann man theoretisch, wenn man das möchte, auch als Development Dependence installieren, dann läuft es ja nicht nach Pipeline.
Und dann kann man quasi, wenn man vor allem für alte Projekte, Fun Fact, in jedem einzelnen alten Projekt, also alt, sage ich mal, 2018 und davor, habe ich mindestens eine Variable gefunden, die nicht mehr da drin sein sollen.
Hat in allen Anfängen keine Auswirkung gehabt, die hat einfach nichts getan.
Aber trotzdem interessant ist, mindestens einmal drüber laufen zu lassen und zu merken, was man vielleicht vergessen hat.
Hat mich auch schon das öfter gebissen.
Also irgendwie einfach ein altes Template genommen und dann mit neuem Welt angefangen, alte Settings halt drin gehabt und dann klappum, hup, huch.
Also wenn man es dann merkt, ist gut.
Jetzt gute die Lösung.
Das Problem, was ich habe mit der Library-Lösung, ist Visibility.
Ja, weil niemand
erfährt davon, dass es das gibt.
Du hast keine Chance, wenn du nicht Carlton Gibson heißt oder sonst was, irgendwo Benutzer für deine Library einzukriegen.
Und jetzt irgendwie so ein Nischen-Use Cases.
Also ich habe so ein Feature, was ich gerne in Django drehen hätte, wo ich jetzt auch schon mit mehreren Leuten drüber gesprochen habe.
Der einzige Grund, warum du hier bist.
Richtig.
Wo ich jetzt mich mal so langsam rantasten werde und es ist auch wirklich was ganz kleines.
Ja, das erzähle ich noch einmal.
Muss ich erstmal mehr politischen Gründen, bevor ich das verraten kann.
Aber okay.
Es wäre eine sehr einfache Änderung und es wäre auch was, was man einfach in eine Bibliothek machen würde, aber wenn ich es in eine Bibliothek machen würde, wäre es unsichtbar.
Niemand würde das finden.
Weil es eine Funktionalität von Django, die in Django Core drin ist, erweitert.
Genauso wie bei der Unre Movals, ja.
Da ist doch ein Warnungsmechanismus drin.
Warum muss ich jetzt nochmal was machen, damit ich andere Warnungen bekomme?
Und ich glaube, dass das einfach, also das ist das, was mich frustriert.
Dass es Dinge gibt, die man mit wenig Aufwand machen könnte, die halt Django erweitern und die Antwort ist, tu es in the Library, ja, okay, aber dann ist es halt für die Discord.
Okay, dann ist für mich Django.
Ja, könnte ich auch machen.
Entschuldigung.
Dann folgen wir uns.
Dann kommen wir dann morgen.
Das nächste Mal habe ich gehört, folgen wir die Django konnten und machen die einfach bei uns in Germany.
Gibt es ein großes Gerücht?
Ja, mal sehen.
Ja, also.
Ich meine, wir Softwareentwickler sind ja, wir mögen das technische Probleme zu lösen und jetzt hier geht es sehr viel.
Bei Karten ging es darum, bei der Jungle Software Foundation ging es um Menschen und das ist doch blöd.
Ja, lass uns mal das selber prone.
Bin noch nicht Softwareentwickler geworden, um mit Menschen zu tun zu haben und jetzt muss ich mit Menschen sprechen.
Schrecklich.
Ich könnte da so eine Coaching-AI fragen.
Ja, aber mit AI sprechen ist ja noch schlimmer.
Warum?
War jemand bei dem Workshop?
Nee.
Nein.
Okay, schade, dann hast du mir nichts auslassen.
Building a unique voting system.
Also nur eine Minute.
Klingt aber interessant.
Ja, hatte ich mich auch.
Aber die WhatsApp, der war halt sehr lang und der hat dann zwei andere Talks übergekommen.
Genau.
Ich habe auch überlegt, ich muss hier, genau.
Und dann ist das nicht.
Nämlich erst rübergegangen und dann habe ich gedacht, ach komm.
Genau, dann gab es noch den How to Enjoy Debugging in Production.
Oh ja, stimmt.
Von der Carrie Tracy.
Genau.
Der war am Anfang sehr unterhaltsam, weil sie nicht.
Eine Kiste?
Weil sie eine Kiste gekriegt hat, weil sie ein bisschen kleiner ist und nicht über dieses Pult gekommen ist.
Das Audio-Setup ist dieses Mal ein bisschen schwierig, habe ich das Gefühl.
Da ist nur ein Mikrofon da vorne.
Ja, das Mastering war.
Ja, das Mastering sind klar.
Ja, sie haben es dann ja quasi so weit
aufgedreht, bis es halt kurz vorm Rückkoppeln war.
Aber es war immer noch viel zu leise.
Ja, das war eine anderen Konz.
Aber das war eigentlich interessant, was sie erzählt hat.
Es war super interessant.
Was hat sie eigentlich, also das Wichtige, was ihr gesagt hat, irgendwie.
Es war aber auch wieder sowas, so ein.
Ja, mach ich so.
Ja, mach ich so.
Kenne ich.
Genau.
Also mach ich für mich, ich kann nichts ausgewähligliches.
Ja, sie sagt halt quasi, dass man für Produktionssysteme ein Logging oder ein Monitoring extra braucht, was auch Allerts kann und dass man es halt dazu bauen muss.
Und dass man halt, also im Endeffekt, ich habe bei dem Talk ein bisschen was anderes erwartet.
Das hat, glaube ich, auch irgendwer aus dem Publikum nachher gefragt.
Weil ich dachte ja eigentlich eher, es ging jetzt darum, wie man halt wirklich tatsächlich in Produktion irgendwas debuggt.
Und ich glaube, ein Großteil ging halt davon, wie man eigentlich vermeidet, dass es so weit kommt, was ja auch genau der richtige Weg ist.
Ja, gut, aber
ich glaube, sie meinte, also Debugging hat sie tatsächlich hinter Logging-Monitoring verstanden.
Also dass tatsächlich automatisiert nach Fehlermeldungen gesucht wird, weil ich glaube, die Menge, die sie hatte, war ziemlich viel, also sowas wie, keine Ahnung, Tausende von Messages, die mal so aufpoppen, dass man die halt ordentlich filtern und nach Prioritäten sortieren kann und sowas und dann halt die richtigen weiterleitet, also dass dann bei jemandem so ein Licht angeht, dass er dann wirklich direkt drauf gucken kann.
Und so.
Und dafür muss man das natürlich alles ordentlich eingestellt haben und sein eigenes Auto betreiben.
Die Antwort auf diese Frage, die da kam, wie vermeidet man denn Fehler in Produktion, war fand ich eigentlich ziemlich gut, weil sie hat halt gesagt, kannst du nicht.
Du musst darauf vorbereitet sein, Fehler in Produktion zu haben und egal was du machst, wenn du mehr Testing machst, hast du weniger, aber du hast sie trotzdem.
Was ich auch sehr interessant fand, also wie gesagt, ich glaube, vieles von dem, was sie gesagt hat, so ja, okay, man sollte Sentry haben, so, das ist eine gute Sache.
Muss ich kurz was einwerfen?
Ich habe jetzt kürzlich gelernt, es gibt Glitch-Tipp.
Glitch Tipp die gleiche AP wie Sentry, das heißt, man benutzt ein Sentry-Client, aber es ist einfacher zu hosten, weil es einfach so wie Century vor fünf Jahren ist.
Okay.
Für die kleinen Benutzer ist das einfacher als Century.
Und wenn man dann groß wird, kann man auch aus Century umstellen.
Ja, cool.
Ja, Entschuldigung, jetzt.
Also was ich ganz interessant fand, ist so diese Sidenotes aus der Praxis zum Beispiel, so diese, jeder kennt das ja wahrscheinlich, wenn man, wenn man einen Entwickler fragt, was ist, wenn nichts passiert?
Das kann nicht passieren.
Was ist, wenn, wenn hier, ne, quasi zum Beispiel man spricht API an und zieht sich die Daten an und dann irgendwelche Nutzer haben dann eine Firma.
So, ja, okay, aber das ist eine Liste, was ist, wenn es zwei kommen?
Ja, das passiert nicht.
Ja, was wenn doch?
Das passiert nicht.
Und genau diese Case sind halt meistens die, die dann dann nachher das Genick brechen, weil dann doch irgendwo der zweite, die zweite Firma kommt und da schon quasi über diese Strategien nachzudenken, bevor sie passieren.
Und nicht zu sagen, also ich meine, es gibt natürlich Cases, wo es sich immer lohnt, die Handbremse zu ziehen, aber selbst wenn das bewusst zu tun und nicht in irgendeinem random tiefen Python-Fehler dann zu explodieren, oder einfach zu sagen, also zum Beispiel, es gibt ja auch so einfach so dumme Strategien, dass man zum Beispiel sagt, oh, ich nehme zum Beispiel einfach die erste Firma und mache einfach weiter.
So, ja.
Je nachdem, das muss halt dann mit dem Kunden oder wer auch immer das dann für die man es baut.
Ich kann einfach finden, ob es richtig ist.
Genau.
Oder dass man es irgendwo vermerkt oder sowas, ja.
Aber ich glaube, dass da kann man sich echt sehr, sehr viel Ärger sparen und vor allem auch den Stress, weil ich meine, im Endeffekt der einzige Unterschied zwischen Produktionsdebugging und lokalem Debugging ist macht ja jetzt nicht mehr oder weniger Spaß an sich, sondern du weißt halt, dass du gerade aktiv hat jemand das Problem und im Zweifel machst du gerade Daten kaputt, die du aufräumen musst, sodass du die Sachen, die es ätzend, machen.
Ja, und du hast auch nicht so viel Sichtbarkeit rein.
Wenn du es lokal
hast, kannst du ja fünfmal hintereinander den Fehler machen.
Gut, ich meine, oft kann man sie auch reproduzieren zum Glück,
wenn du irgendwie eine Möglichkeit zum Beispiel.
Also wir haben in mehreren großen Systemen das so eingebaut, dass wir so einen Job haben, der anonymisierte Dumps postet.
Da gibt es ja auch ein cooles Package, auch aus Stuttgart.
Django Scrubber heißt das.
Da kann man über so eine Meta-Klasse quasi über Faker definieren, wie Daten anonymisiert werden.
Also das heißt, du hast dann quasi produktionsnahe Daten zu random Daten, mit denen es keinen Spaß macht zu arbeiten und die auch meistens irgendwie nicht ins CY passen und so.
Also Django Scrubber könnt ihr euch mal anschauen, auf jeden Fall.
Das ist auch, was für sie meinte, ne?
Also so Staging erzeugen, dass von der Datenvolume genauso groß ist wie bei.
Sie hat das nicht gesagt, aber im Endeffekt, das ist, glaube ich, das, was sie gemeint hat.
Und wir haben halt dann immer so ein S3, also in den größeren Projekten ein S3-Bucket, wo dann halt diese quasi, ne, so dieses, dieses typische logarithmische von der letzten Stunde, von der letzten Nacht, vom letzten Tag, von der letzten Woche, vom letzten Monat, die Dumpstern liegen, die auch immer aufgeräumt werden, die kann man sich dann halt runterziehen und dann sagen, okay, da ist jetzt irgendein Bug mit User 27.
Man kann ja Sentry auch so einstellen, dass die IDs geschickt werden nach Century, aber alle personenbezogenen Daten, also per Default nehme ich alle User-Daten raus, also man kriegt gar nichts mit.
Was natürlich schwierig ist, wenn man nicht weiß, was ist der Content.
Aber das kann man relativ einfach ein Miniskript schreiben, was am Ende alles, was man nicht in Century haben möchte, rauswirft.
Das heißt, vom GDPR ist man super safe und dann hast du halt die User-ID in Century, kannst damit das dann nachstellen, hast du vielleicht noch die Produkt-ID, wo jemand geklickt hat, keine Ahnung.
Und damit kann man viele Probleme, klar, wenn du irgendwas ganz fieses mit Concurrency oder verteilte Systeme oder sowas, das ist nochmal ein anderes Problem, aber ja.
Ja, ein solches System macht man halt
einfach keine Fehler.
Stimmt.
Darum ist das
auch einfach absolut gesehen besser.
In jedem Fall.
Es gibt ein Zitat von Donald Knuth, der geschrieben hat, Beware the above code, I've only proved it, not tried it.
Also passt auf, was er mit diesem Code macht.
Ich habe nur bewiesen, dass er richtig ist, aber ich habe ihn nicht ausprobiert.
Ganz der Mathematiker.
Ja, da gibt es noch so einen Anspruch, ich weiß jetzt gar nicht mehr von wem, sagt dann, so Definition von funktionierender Software, also funktionierender Software kann man nur so nennen, wenn sie zumindest in Produktionen gewesen ist und da gescheitert und man sie dann schon mal ein paar Mal verbessert hat.
So vorher kann man nicht sagen, dass sie funktioniert, weil wahrscheinlich muss man
erst nochmal dadurch.
Dann gab es noch einen Vortrag und zwar 100 Millionen Parking Transactions per Year mit Django.
Ja, die
meinen halt mit Transaktionen was anderes als andere Leute, daher war das so ein bisschen verwirrend für mich, aber sie meinen aber tatsächlich, wie viele
Leute sich so ein Parkzettel parkenzen.
Hat er gesagt, gibt es verschiedene Sorten.
Je nachdem wurde Backup von den Parkplätzen in den Niederlanden, oder?
Ja, und jetzt auch in Deutschland, hätte er auch gesagt.
Ja, genau, da war langsam reinwachsen.
War aber nicht auf der Karte drauf, hätte mich jetzt hinterher.
Ja, ich habe auch so eine App, ich weiß nicht, Pay by Phone oder was das heißt, vielleicht benutzt ihr was ähnliches oder sogar den gleichen Intervussion.
Ja, war, also da waren schon viele schöne Sachen drin und das ist halt schön zu sehen, dass man halt irgendwie, das sind ja nur irgendwie vier Leute oder so und die machen das halt quasi für alle Parkplätze und das haben wir Demo und das funktioniert super.
Es war also ein ETL-System haben die gebaut.
Genau, die haben so IT-System mit Django Admin gebaut, ne?
Das fand ich so ein bisschen besonders.
Weiß ich nicht, ob ich das mache.
Was ich denn dann gedacht hätte.
Also, ne?
Du musst Daten erst irgendwo herbekommen und dann musst du dich transformieren und wieder drücken.
Also Extract, Transform und Load.
Genau.
Weiß ja nicht jeder.
Aber es ist trotzdem interessant, dass es mit dem Django Framework, dass es auf der Skala funktioniert, dass die es mit vier Leuten maintained bekommen und sich auch noch gut dabei fühlen, sagt er.
Das würde ich unterschreiben, ich hatte das Autos gehört, dass es gut geht.
Ich glaube, es gibt viele Setups, wo du das nicht mit vier Mann hinbekommst.
Absolut.
Das ist so ein bisschen der Takeaway, oder?
Wie weit du es treiben kannst.
Es müssen auch vier gute Leute sein dann tatsächlich, die das gut organisieren können, weil es weiß ich ja.
Ja, aber das kam auch.
Es gibt beide gute Leute
und einer macht das, worauf
auf die anderen keinen Bock haben.
Das kam auch bei diesen anderen Talks, bei dem Haki Benita.
Gestern bei dem bei dem, wie man von Integer zu Big Integer wechselt, wenn du mehr als eine Milliarde Zeilen hast.
Da kam das durchaus für mich so ein bisschen raus, wie weit man mit diesen Tools gehen kann.
Wie viel Schmerz sie doch die meiste Zeit von deinem Fernhalten.
Man könnte ja jetzt, also wenn man, wir haben ja vorhin über diesen Talk von Haki Benita gesprochen, da könnte man jetzt rausziehen, dass das Migrationssystem blöd ist und dass man gleich von Anfang an SQL machen sollte und lieber eigene Indizes und so weiter.
Aber für mich das Fazit ist ein anderes.
Für mich das Fazit ist, du kannst es eigentlich so machen, wie du willst und sobald du dann an die Grenze stößt, gibt es trotzdem Mittel, um über diese Grenze noch hinauszukommen.
Und auch unkompliziert.
Weil es war ja kein Hexenwerk, was er gemacht hat.
Ja, und er hat auch gesagt, wenn es eine Möglichkeit gibt, das mit den Django-Mitteln zu machen, dann macht er das, weil es einfach komfortabler ist und zukunftssicherer und Datenbanktransferierbar und so weiter.
Und das ist so ein bisschen eine schöne Bestätigung, dass man eigentlich sich erstmal keine Sorgen drüber machen muss über den Erfolg.
Ganz viele Leute machen sich dann Sorgen, was ist, wenn ich mal eine Million User habe?
Okay.
Zu viele Sorgen über den Erfolg gemacht.
Und für mich ist das so ein bisschen die Botschaft.
Man kann das machen und es funktioniert.
Wenn ich immer drei Nutzer habe, vielleicht funktioniert es ja dann auch trotzdem.
Ja, das vielleicht.
Beim ersten geht's noch, beim zweiten.
Als Mathematiker der größte Sprung ist eigentlich von 1 zu 2.
Alle anderen sind dann egal.
Ja, man kann ja auch nur noch mit Agenten reden, ja.
Ist das dann schon viele?
Agent ist dann ein anderes Thema.
Anderes Thema.
Genau, das war's.
Jetzt ist gerade Mittagspause.
Ja.
Es war Mittagspause, wir haben schon was verpasst.
Ja, es läuft schon wieder was.
Aber was tut man nicht für seine Hörer?
Ja, dann schaltet uns wieder ein.
Vielleicht morgen wieder, wir wissen es noch nicht ganz genau.
Ja, mal schauen.
Ja, morgen ist auch noch die Partyabend und wir können ja nicht eigentlich, oder vielleicht am Samstag noch eine.
Ja, schauen wir mal.
Ja, also wie auch immer, wenn ihr uns wieder hört, bleibt uns geflogen, schaltet wieder rein.
Hallo at pythonpodcast.de für alles Feedback.
Vielen Dank, effektiv am Ende.
Danke.
Wir machen heute Abend noch.
Danke auch.
Ja.
Und ja, dann.
Bis zum nächsten Mal.
Tschüss.
Ciao.
Ciao.