Transcript: Live von der DjangoCon Europe 2025 in Dublin - Tag 2
Full episode transcript. Timestamps refer to the audio playback.
Hallo liebe Hörerinnen und Hörer, willkommen beim Python-Podcast, Episode 64, heute nochmal von der DjangoCon, eine Sonderausgabe.
Ja, zweite Live-Episode.
Ja, freut mich wieder da zu sein. Hey Jochen.
Ja, hallo Dominik.
Hallo Johannes.
Hallo zusammen.
Und hey Ronny, heute alles ganz.
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 DjangoCon erzählen, auf der wir gerade sind in Dublin.
Ja.
Das hatten wir 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 unterschiedlich.
Ich habe noch mein Sweater vermisst und dann habe ich mein Sweater gefunden. Das war wahnsinnig gut.
Dann hatte ich aber meine Hotelzimmer-Eintrittskarte nicht.
Am ersten Tag einmal alles mitgebracht.
Ja, und wenn man das Zimmer wechselt, ist auch schlecht.
Ja, genau.
Alles anders.
Ja, aber es hat irgendwie alles geklappt.
Es ist immer noch da.
Wir haben ja gestern bis zum Mittagsscheit erzählt, was so war.
Was war denn gestern noch Interessantes?
Oh, jetzt müssen wir zurück scrollen.
Tan, es tut mir leid, du warst schon bei heute.
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.
Ja.
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.
Ja, nachdem 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 Spa-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.
Kurzes Sidenote, bevor du runtergehst.
Den Talk mittags von Sebastian
hattet ihr den besprochen, weil der ist ja auch aus der Region
bei uns, aus Köln.
Achso, den hatten wir nicht besprochen.
Nee, den hatten wir nicht besprochen.
Genau, da freue ich mich
ein bisschen, dass es geklappt hat, weil er hatte mich
noch gefragt, weil ich
ja schon mal letztes Mal bei der DjangoCon
mich beworben hatte und
genommen wurde, wie es
denn aussieht und
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 erst mal kurz, worum ging es denn überhaupt?
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, lies die Release Notes,
abgesehen von dem einen mega krassen, geilen Feature,
weil man halt
da sehr viele Dinge immer kommt, die einem das Leben
leichter machen, wo man Coach sparen kann,
irgendwelche fiesen Hex-Walkarounds ausbauen
kann und hat sich dann dadurch die
5.x-Version 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
vermeiden lässt. Genau.
Und genau, freut mich sehr, weil der ist jetzt auch bei
auch ein Regular beim
Colone-Meeting, Jungle Colone.
Was hat der denn alles Schönes
erzählt. Vielleicht kannst du so ein paar
Da fragst du mich Sachen, es ist immer so schwer, sich in Details
zu erinnern, wenn man sich am Tag
Wenn man nicht so Notizen hat wie der Johannes hier vor
Ja, ich war aber nicht in dem Talk, deshalb habe ich keine
Notizen zu dem Vortrag
Es ging um
diverse Verbesserungen im Admin
Es ging um Custom Error
Messages, die man jetzt bei Constraints
hinterlegen kann, die auch übersetzbar sind
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 war ein ganz
Also selbst wenn man jetzt sagt, oh, diesen Case hatte ich noch nie, ich muss noch nie eine Custom Unique Constraint definieren, dann war halt immer so, ah, aber das sieht tatsächlich nützlich aus, weil diesen Fall kann ich mir nicht vorstellen, weil man ihn halt präsentiert bekommen. 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 scheinbar das Frontend auch nicht so genau gelesen.
Ja, dann hat er es gut gelöst.
Das ist 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 dann auch 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 Pony Express Package,
habe ich nach der Django Con Vigo 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 Text, also Inhalte.
Also die kann theoretisch Medieninhalte haben.
Es gibt den HTML-Inhalt und den Plaintext-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 in dem Package für die Testsuit einen Wrapper geschrieben.
Also die Testsuit nicht fürs Package, sondern für die E-Mail-Klassen,
die man produziert mit dem Package.
Und habe dann vorgeschlagen, ob das nicht ein relativer No-Brainer wäre,
wenn man sowas auch irgendwie den E-Mail-Alternatives geben könnte.
Das ist quasi alle, also diese, wie nennt man das, dieses Text-slash-JavaScript-Script-slash-irgendwas,
diese, ich komme gerade nicht drauf, Name-Types?
Diese Trainer-Types.
Content-Types, genau.
Ja, ach so, 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 ersorgen 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 habe 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 den Talks.
das ist ja gleich mal echt so eine blöde Idee.
Ja, der nächste war Solving a Python Mystery.
Ah ja. Oder wart ihr bei jemandem bei dem
Quality-Workshop? Den da
war ich auch nicht drin. Nee, leider nicht.
Wollte ich zwar auch irgendwie, aber irgendwie
hat es nicht geklappt.
Genau, Solving a Python Mystery, der war
großartig. Aber der war gut, der war sehr gut.
Insofern ist er jetzt nicht so traurig. Nicht so, dass ich den jetzt
anwenden könnte, aber einfach mal
mit SJS überall reingucken
und schauen, was da für Dateien
offen sind und so.
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
und man hat bloß halt
vielleicht Log-Files oder man kann nur extern drauf gucken,
man kommt nicht in die Prozesse rein. Ja, oder hat man
eine eingeschrä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
Proc-File-System kommt man da halt dann ran
und dann hat man die ganzen
Credentials, die man so braucht, um halt in die anderen Sachen
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 halt auch
sich angucken muss. So wie viel I.O.
Operationen pro Sekunde gibt es denn eigentlich auf der
Maschine? Was macht die denn? Was schreibt die?
Was lief 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 und 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 einen Kafka-Cluster, statt halt mal zu gucken, warum das nicht so richtig funktioniert.
Genau, war da halt so eine Geschichte, TCP, No-Delay kann man irgendwie setzen, wenn man…
Macht Python ja auch an Stellen weit.
Genau, macht Python.
Der Kafka-Client macht es nicht.
macht es 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? Ich weiß nicht.
Es war schon, es ging schon
sehr weit runter in den Kernel. Das war eigentlich
das Interessante, dass der halt nicht
Python debugt hat, sondern er hat eigentlich
Linux und File Handles
und Kernel Traces debugt.
Ja, also von außen solche Sachen,
debuggen, das ist eigentlich super einfach.
Und dann hat er ein Diagramm irgendwie auf einer Slide
gezeigt und das war 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 Syscrolls selber tracen,
du kannst eigenen Code in den Kernel
injecten.
Ja, das hört sich simpel an.
Der dann im Kernel
vom Kernel formal bewiesen wird,
dass er nichts Böses tut und dann ausgeführt werden kann.
Ja, dann.
Und jemand, den wir
auch schon im Podcast hatten, Martin, hat dafür
einen Python-to-intermediate-language
Compiler mal geschrieben.
Dann kann man das auch in Python machen.
Er meinte auch, das verwendet er auch häufig,
wenn er noch mal tiefer
gehen muss.
Ja, ansonsten weiß ich,
ich kann mich nicht mehr so wirklich erinnern an alle
Details, aber es war halt so, ja, also man
muss immer mal gucken und
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 in unserem Berufsfeld 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.
Er meinte auch erst, wenn er irgendwo einen 500er-Fehler sieht oder sowas, dann kann er nicht mehr schlafen.
Er muss das irgendwie rauskriegen.
Das geht auch ohne Unix-Debugging.
Danach war der Celery-Vortrag, also der Parallelisierungsvortrag mit Celery.
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 eine Bestätigung, dass die Sachen, die ich rausgefunden habe, nicht ganz abwegig sind.
Und die waren?
Ja, dass du Tasks in möglichst kleine Teile aufteilst, dass du ein Modell hast mit einem Status drauf, dass du den Status atomar änderst.
Also in der Transaktion machst du ein Select for Update auf dieses Modell, änderst den Status, speicherst den.
Das hat er nicht gezeigt, dann mache ich es normalerweise so, dass ich an 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 so was, ich weiß nicht,
vielleicht bin ich da als Einziger draufgekommen oder auch nicht.
Und dieser Vortrag war so ein bisschen die Bestätigung,
ich bin nicht als Einziger draufgekommen.
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 transaktionsfroh angefasst
und du füllst das dann auf Dinge,
die auf dieses Statusmodell...
Ja, und wenn du in so ein Task reingehst,
dann erwartest du,
dass das Objekt, was du bearbeitest,
in einem bestimmten Status ist
und änderst es in einen anderen Status,
damit kein anderer Task das anfassen kann.
Direkt am Anfang?
Ja, das ist das allererste, was du machst,
bevor du irgendwas anderes machst.
Änderst du das auf ein Processing oder sowas?
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, ich meine, du änderst
das nicht direkt in den nächsten, sondern in den
Intermediaten. Sondern du änderst das 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 da drauf
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 Prozess
Schritt gehen kann. In der
einfachsten Stufe ist es, du hast einen, der ist
Pending, dann hast du Processing und dann hast du Done.
Aber du kannst
natürlich diesen Aufbau, kannst
natürlich x Stufen haben. Du kannst ja 5
verschiedene Verarbeitungsschritte oder 100 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
Datenbanktransaktion, 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 hat es 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
dich quasi davor, dass du
diese Race Conditions in die Datenbank rein
trägst. Dass du sagst,
okay, der verarbeitet jetzt was und der
verarbeitet jemand anderes auch noch irgendwas.
Und er hat das gestern Idempotency
genannt, also Idempotenz.
Meiner Meinung nach nicht 100% korrekt
genannt. Darfst du es ja nicht
ein paar Mal ausführen.
Weil Idempotenz eigentlich bedeutet, wenn du es mehrmals
ausführst, hast du das gleiche Ergebnis.
So ein bisschen
der Outcome
ist das gleiche. Du hast zwei nichtige
Begriff dafür. Korrekte Idempotenz.
Naja, der korrekte Begriff wäre hier
irgendwie Locking oder sowas.
Du hast einen Lock da drauf und das
hast du so eingerichtet, dass es wirklich nur eine 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.
Oh, ich weiß nicht,
leider. Das ist dir noch nie passiert.
Bei mir passiert das 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
dann auch so Dinge mit Workflows und keine Ahnung,
das ist kompliziert. Und ich denke so, ha, lieber nicht, so was
macht man das nicht. Wie ist denn jetzt der Stand mit den
Dango-Tasks? Die sollten doch jetzt langsam
mal. Ja, ist aber noch nicht. Die kommen auch
irgendwann. Kommt jetzt dann vielleicht demnächst.
Aber ich glaube, es geht ja vor allem nur ums
Interface erstmal. Es gibt ja
dieses Package, wo das jetzt erstmal
quasi so eine Art, ich glaube, die Datenbank-Task
als Primärding
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, mit Vorname-Nachname-Konzept,
das passt oft nicht in vielen Use-Cases
oder auch anderen Kulturen,
dann viele, also es wird dann username-standardmäßig
genutzt, du kannst das irgendwie opt-outen,
es gibt so Packages, E-Mail-Adresse
ist nicht unik, also ganz viele Dinge und
das eigentlich 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-and-Play
macht, wie halt auch die Datenbank-Anbindung
Plug-and-Play ist, wie die Caches Plug-and-Play sind,
wie mehr oder weniger eigentlich alles Plug-and-Play ist
und da ein Authentifizierungssystem
zu haben, wäre natürlich super und ich glaube, die auf diesem gleichen
Konzept basiert auch dieses Tasks,
ist im Endeffekt das Django Core, im Endeffekt mit
jedem kompatiblen Task-Runner
oder Task... Ist es Task-Runner? Ich weiß es
nicht genau, was die dann... Background-Task
Backend.
Ja, Backend, genau. Task-Backend
dann kommunizieren kann, wenn man dann sagt, ich möchte
ein Eins mit Celery, dann baust du dir eins und wenn du
sagst, mir reicht die Datenbank, dann baust du dir
dafür eins oder nimmst das, was da ist und
das... Ja, ich warte
da aber auch schon sehnsüchtig drauf.
Wir können auch noch kurz vorgreifen auf einen der
Lightning-Talks, weil da war noch mal
der...
der Mann da, der auch über die Python-Mystery gesprochen hat
und hat mit so ein kleines bisschen Zorn gesagt
hier, Celery, das ist alles Mist
und das ist viel zu viel Aufwand
und deshalb habe ich mir mein eigenes geschrieben.
Und das Interessante daran war,
dass er das gleiche Interface benutzt hat
wie das von Celery. Also das ist nicht
das Django-Tasks-Interface, sondern
das von Celery. 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 man zurück. Fand ich auch
eine interessante Idee.
Was ich daran sehr interessant fand, ist,
dass wenn man viele nutzen,
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? Ja, aber
das wird immer, das ist rot umrandet
und da habe ich nicht. So, das heißt, die
meisten Leute nutzen halt dann Redis oder Revit im
Queue, irgendein Derivator von 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
damit Redis-Issues gibt, das ist da seit
also wir, uns ist das glaube ich 2018
auf die Nase gefallen
und unser
wir haben ja immer gesagt, okay, dann nutzt man Redis-MQ, 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, so
aber du kannst ja auch einen Scheduler verwenden, du kannst andere Sachen
wir haben das wirklich mehr oder weniger
gut ausgebaut bekommen, kein Problem mehr, Kuh vom Eis
und dann meinte dann
in einem Lightning-Talk erst, da meinte er so,
ja, ja, ihr denkt, ihr nutzt
die nicht. Aber in dem Moment, wo
ein Retry kommt, nutzt 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 Celery verwenden.
Ja, Ivar Skalvans
ist der Name.
Ich verstehe auch nicht so genau, warum
mit dem Schedule, das funktioniert immer nicht so,
wie man das richtig will. Und das Package
heißt übrigens Django
minus Task Q, also
wie der Buchstabe. Das heißt, irgendwer mal
Spaß daran hat, das auszuprobieren. Ja, es gibt leider so ein bisschen
viele Django-Task-Sachen, die alle so
ganz ähnlichen Name-Mangels sind.
Ja, kann ich verlinken, auf jeden Fall.
Genau.
Genau, dann kam so ein bisschen,
ging es so ein bisschen ins Abendprogramm rein, da war es schon
17 Uhr und
dann kam der Words-Vortrag.
Lock, Shells, Caches and other strange words.
Von einem
Dortmunder, das fand ich auch interessant.
Ja, das ist auch relativ nah bei uns dran,
aber noch nie gehört.
Nee, ist ungeheuer weit weg, finde ich.
Ja? Ja, gut.
Hörertreffen in Stuttgart.
Die machen sie jetzt dafür ab.
Genau, der Vortrag...
Wir haben übrigens ganz kurz zum Hörertreffen
schon uns entschieden für...
Er kam ja immer noch um.
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, 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 kommt, dass das nicht stimmt.
Also, dass das nicht die Ursache davon ist. Das habe ich schon oft rumerzählt.
Das ist auch ein schönes Bild.
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 und dann in ihrem handgeschriebenen Logs, also wirklich das, was heute halt auf dem System irgendwie im Hintergrund läuft, in einem Buch.
Und da hat sich die Motte eingeklebt und hat das dann so geschrieben als, 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, sein Ideenfindungsprozess ist so, wenn er eine neue Idee hat, dann kommt das so in einem Schwall heraus und danach kommen wie kleine, wie kleines Ungeziefer, diese ganzen Probleme in der Realität, mit denen er 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 ihr, 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.
Ja, 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 erfindest du die Glühbirne nicht.
Ja.
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. Machst du ein bisschen Spoiler?
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 heute Abend dann fünf Minuten Zeit.
Mal schauen, 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, habe es dann 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.
Morgen ist ja auch schon voll, habe ich gehört.
Auch schon voll, heile nein.
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-DevOps-Geschichte
in so einem großen Monolithen brauchten.
Es hatte zu tun, ganz konkret, um Django Migrations aufzuräumen
für einen relativ spezifischen Case, für ein Projekt mit sehr, sehr langen
Deployment-Zyklen und so.
Und ja, das aus Gründen nicht funktioniert hat
und so wegen der Circular Dependencies auflösen,
dauert zu lange, etc., etc.
Auf jeden Fall habe ich dann mich relativ stark dafür eingesetzt
und habe da beim Kunden auch so ein paar Hierarchie-Ebenen,
Hierarchie-Träbchen 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.
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.
Weil man dann endlich eure Fehler finden kann, die dann auch öffentlich verfügbar und einsehbar sind.
Vor allem auch, weil wir ansonsten das halt irgendwie den Monolithen 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...
Open Source war also ein Maintaining-Versprechen. Interessant, ja?
solange ich mich drum kümmere zumindest.
Da war die Kinderplanung
noch nicht so weit fortgeschritten.
Wird mich wahrscheinlich irgendjemand auf meine
Python-Podcast-Folge von vor zwei, drei Jahren
festnageln, wo ich gesagt habe,
das muss man immer weiter maintainen.
Nein, genau.
Man kann ja auch schlecht maintainen.
Ich maintaine Sachen aber teilweise
sehr, sehr schlecht.
Nein, aber vor allem, dass das Schöne an der Geschichte ist,
nachdem ich das gemacht habe,
den Artikel darüber geschrieben habe,
und es halt wirklich auch im Endeffekt eine Win-Win-Situation war,
auch wirklich die Entkoppelung auch dann da, weil 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 sogar literally as to do im Code,
weil ich wusste, dass ich das eigentlich noch fixen muss, aber
ich brauchte es halt für einen 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 Merge-Requests,
wo ich wirklich absolut oder fast nichts daran 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 Access-Story verkaufen
und ein bisschen Werbung zu machen.
Was war das genau? Worum ging es da?
Also ich habe, du hast gesagt, Deployment-Zeugs bei Django.
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
Mig Zero und Migration Zero Django
und ich glaube Migration Zero ohne Django.
Ja.
Ich habe einen Artikel, ich habe in Blog-Posts
das verlinkt und noch einen Artikel drüber geschrieben.
Das heißt, Google packt mich jetzt auf Platz 1, glaube ich.
Yay!
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, in unserer Toolbox-Package, wo so kleine Dinge, die sich nicht als eigenes Package lohnen, haben wir quasi so dieses Created-By, Last-Modified-By und das Ziertel auf den User, was dazu halber 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 Auth,
wie immer mit auch Modelswitchen und haben wir meistens uns für ein Custom-Model entschieden,
was wir heute nicht mehr tun, aber es war halt ein älteres Projekt.
Und das heißt, du hast sehr, sehr, sehr, sehr viele Circle 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 Packages-Deployed-System.
Also was auf ein Produktivsystem angekommen ist, da ist Ende.
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.
Und startest halt neu.
Haben wir alle schon oft gemacht.
Create Migrations lustigerweise nicht das Problem
hat, was Squashing hat. 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
Du hast die Datenbank schon einmal so gezogen, dass der Stand
stimmt und dann schmeißt du alle Migrations weg und machst neue Migrations hin.
Genau und du musst halt, du kannst halt
in ganz, ganz fiese Edge Cases kommen, die nicht
so alt 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 die Django Migration Table
im Endeffekt den
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,
dass das für einen macht und du kannst es von Django Admin
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 ihr das quasi für
einen selber, das heißt, du musst nicht mehr auf der
Datenbank rumfrudeln, 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 konvenient.
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, dass das Problem ist,
ich glaube, Django lädt sehr, sehr, sehr, sehr, sehr stark dazu ein,
dass man so gewisse zentrale Models mit immer mehr belä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.
Also Profil ist für euch ein eigenes Modell,
eine eigene Tabelle oder Zeug?
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-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, das ist vielleicht gerade kein Beispiel,
aber zum Beispiel, wenn ihr sagt,
ich habe irgendwelche Konfigurationen,
die ich machen kann in meiner Applikation,
dann gibt es vielleicht ein User-Konfigurationsprofil.
Und versucht das aufzuteilen und dann die verschiedenen kleinen Models in ihren Domänen zu haben, was halt auch dazu führt, dass du, wenn du zum Beispiel den User immer weiter aufbläst, teilweise hast du dann ja 50, 60 Felder in einer hinreichend 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, also gegeben der Last, aber auch immer einen relativ großen Overhead. Plus ist natürlich auch für den nächsten Junior, der ins Projekt kommt, der muss halt 50 Felder verstehen und nicht nur drei.
Das mit Daten habe ich
noch nicht drüber nachgedacht, aber ich habe jetzt tatsächlich User-Profile
an ein Profile-JSON-Field
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 Relational-Datemark-Adaptsodum.
Manche Dinge sind die super.
Ja, für solche Sachen im Profil möchte ich das nicht filtern.
Also das ist nicht so Filter-Rebuild.
Aber ich sage mal so, ich versuche die,
ich nutze die, aber ich versuche
da dreimal drüber nachzudenken, ob ich es wirklich nutzen möchte.
Und wenn ich zum Beispiel so die Profil-Konfiguration
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 übergegangen, Custom User Models
zu machen, aber nicht um
da Felder hinzuzufügen, sondern eben genau um Felder
wegzuschneiden, weil ich keinen First Name brauche, ich brauche keinen
Last Name, ich brauche keinen... Ich habe auch alles
gestrichen, 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 der tatsächlich
ich meinem eigentlich gar nicht.
Ja, genau. Das ist eigentlich das Gleiche.
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 so was,
dass man baut sich ja dann irgendwie so eine
Sammlung an so eine Schatzkiste an Lösungen
auf und die benutzt man dann schon immer wieder.
Und wenn die je verloren geht, dann bin ich wieder
ein Jumbo-Anfänger.
Darum haben wir damals mal angefangen,
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, 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 ja so ein kleines kariertes Maiglöckchen 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 genauso aussieht wie man es kennt.
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 ist der Zeitpunkt gekommen, wo das nicht mehr relevant ist oder habe einfach Sachen aktiv rausgezogen. Also mit das Pony Express Package, von dem ich vorhin am Anfang gesprochen habe, das war auch mal Teil davon. Habe ja gesagt, das ist sowas von Single Purpose. Also das macht keinen Sinn, das da mit reinzufudeln.
Das kann man gut rausziehen.
Genau.
Cool.
Dann sind wir mit gestern durch.
Dann kommen wir nach heute.
Heute der Tag hat angefangen.
Er hat sehr früh angefangen.
Einer, ihr habt so früh überlassen, auch wenn ich nach unserer Zeit neun Uhr nach Lokaler...
Mein Jetlag ist schon vorbei.
Ich fand es jedenfalls interessant, es war ja...
Es war der Talk für die Django Software Foundation, die Versammlung und der offizielle 20. Geburtstag.
Ja, war ja gar kein Talk, sondern es war das Django Software Foundation Board Meeting.
Ja.
Das jährliche Board Meeting, das erste jährliche Board Meeting.
Weiß noch nicht, ob man davon jährlich sprechen kann.
Gleichzeitig die Geburtstagsfeier, 20 Jahre Janko, es gab auch Kuchen.
Es gab Kuchen, ja.
Das war sehr schön.
Aber es war halt heute früh um 8 und mir ist durchaus aufgefallen, dass dann so um 8.10 Uhr noch ein paar Leute gekommen sind.
Oder um 8.15 Uhr oder um 8.20 Uhr.
Oder um 8.30 Uhr, wie ich.
Es scheint tatsächlich nicht ganz einfach zu sein, so früh aufzustehen.
Ich meine, mit Kindern ist das eigentlich so, ja.
Ich kam halt aus der Stadt und die Busse fahren so mittel von da ab.
Ja, okay, gut.
Das ist natürlich ein bisschen...
Ja, der Bus ist ein eigenes Airbnb-Sus.
Wir sind ja alle im Hotel, da ist es natürlich einfacher.
Ja.
Ich habe jemanden gesehen, der mit
Badelatschen die ganze Zeit,
da dachte ich mir so, oh, warum bin ich da nicht drauf gekommen?
Ich nehme die Schuhe an.
Ja, ich habe mich auch nicht gedacht, ich wollte eigentlich gerade eben nochmal
ins Gym.
und Steam, aber dann muss ich mit Bademantel
an der Konferenz vorbei und kurz winken.
Mit Bademantel zur Konferenz gehen.
Das habe ich mir auch überlegt.
Solange der Bademantel zu ist, ist doch alles okay.
Das ist auch eine Frage.
Ich passe da immerhin rein, ich habe ja nämlich meinen eigenen Bademantel.
Das haben wahrscheinlich auch nicht so viele.
Okay, also das Jungle of Software
von der 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
Zeit man mit so Dingen verbringen kann.
Ja, richtig. Auch wie viele Meta-Dinge
einfach passieren müssen und wenn sie
nicht passieren, wie viele negative Konsequenzen
das hat. Und wie viele Kommentare es gibt
zu allem. Ja, da muss man noch mal reden,
jeder darf auch was dazu sagen und dann wird dem auch zugehört.
Also, sehr
Corporate.
Und dann gab es Kuchen, das war sehr schön.
Ja, das hat sich gelohnt,
früher aufzustehen 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 Mainhall.
Nee, das heißt ja Mainhall, ich meine.
Gab es den? Habe ich den verpasst?
Nein, da war es auch der Most Bizarre Software Bugs in History.
Ach so, ach so, ja, das ist, ja, okay, klar.
War eine schöne Aufstellung.
Hast du, hat der Jochen
den Lightning Talk vom Johannes vorher schon gehört?
Ich habe ihm das vorher kurz
gezeigt, das war
eine Pause.
Das war nur der Vulkanier
Mindgrab.
Genau, das war auch eine sehr schöne, war sehr unterhaltsam.
Dieser Vortrag war erstaunlich lang.
Er hat viele Sachen
gesagt und viele von den Geschichten
kennt man ja schon so ein bisschen.
Man hat es ja schon mal gehört.
Ein Lion Air Flight 110
und
ich habe gar nicht mehr die Geschichten
alle notiert. Ich habe nur notiert, wie die
Geschichten heißen.
Das mit der Mars-Mission, mit dem metrischen System.
Vielleicht gehen wir noch mal kurz
darauf ein. Also ein Bagger ist natürlich
in den Flugzeug abgestürzt, nicht so gut.
Es sind zwei sogar, es sind zwei abgestürzt, wo was passiert ist.
Boing, so ein System eingebaut hat,
dass die Nase immer korrigieren sollte und dann ist
der Sensor ausgefallen, der hat nur einen eingebaut und dann
Und die Piloten wussten nichts davon?
Ja. Bei dem zweiten Flug, der war
sogar noch ein bisschen tragischer,
weil da wussten die Piloten davon.
Haben es nicht abgesteckt gekriegt.
haben es nicht abgeschaltet gekriegt und vor allem
dieses System ist gekoppelt
an den Steuerknüppel.
Das heißt, die haben versucht, an dem Steuerknüppel zu ziehen
und das System hat dagegen gedrückt und irgendwann
konnten die nicht mehr.
Und das finde ich noch viel tragischer, wenn der
halt gegen die Maschine kämpfen muss
und die Maschine in dem Moment will dich
umbringen, so fies gesagt
und dann gewinnt sie auch noch.
Das ist hart, das ist echt hart.
Und dann, genau,
nachdem diese beiden
Flugzeuge abschürzt waren, ist ja auch die
gesamte Flotte einfach stillgelegt worden
mal für einen Moment, bis sie
bis zu einer neuen Zertifikation durch war.
Ja, die, die ja, ja.
Also es war eine wirklich schöne Aufstellung
von Dachern und so ein bisschen Hinweis.
Auf der Mars-Mission ist vielleicht auch noch interessant.
Ah ja, Mars-Mission, ja. Auch klassischer
Fall. Ja, weil es dann einen kleinen Bug gab zwischen
Umrechnung, zwischen metrischen und
nur ein kleinerer. Wer ist nochmal das andere System?
Genau, das eine, das imperiale.
Genau, das eine hat halt
den Zoll gerechnet und das andere hat den Millimeter
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 England gewonnen zu haben, aber damit 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, das habe ich auch zum
Jochen schon in dem Vortrag gesagt, ist auch so ein gewisser
Power-Move von der Erde, dass wir da hier
Jahre und Millionen reinstecken und dann einfach
zack.
Blüte im Orbit.
Ja, und dann die anderen Geschichten.
Da gibt es ja viele so Geschichten.
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 ja betrifft, und das ist tatsächlich
auch immer eine sehr hübsche Fehler,
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 einen vor dem Gröbsten irgendwie
bewahren,
Die gibt es da halt nicht.
Man kann auch Excel dann das nachbauen.
Bitte?
Man kann das dann auch nachbauen.
Ja, aber hast du schon mal gesehen,
dass jemand Excel-Sheets in quasi...
Habt ihr keine Unit-Tests auf euren Excel-Sheets?
Ja, oder Unit-Tests oder irgendwie ein Repository eincheckt
und das gibt es alles irgendwie nicht so richtig.
Ja, ich habe...
Nee, das geht alles über E-Mail.
Du hast die Leiste von zwei Jahren nachgebaut.
Das war eine ganz tolle Erfahrung.
Ja.
Ach so, du hast das mal nach...
Oh Gott.
Genau.
Das kann ja dann auch...
Also sie hat ja da so ein paar Sachen erwähnt,
die einfach richtig schlimme Folgen haben.
JP Morgan hat halt
eine von den Berechnungen, haben sie
addiert,
statt zu mitteln.
Und dann haben sie ihre Risikobewertung einfach
um Faktor 2 falsch gehabt und Milliarden an Dollar
verloren.
Ja gut, als Softwareentwickler
sagt man, selber schuld.
Hättet ihr mal von uns gehört.
Als Bank heißt es so.
Passiert mir jedes zweite Wochenende.
Ja,
sechs Milliarden unter Freunden kommen.
Ja, genau.
Also es war wirklich eine schöne Zusammenstellung, war sehr unterhaltsam, war ein guter Anfang.
Sie hat auch einen sehr guten Vortragsstil.
Ja, war wirklich sehr angenehm.
Ja, was gab es denn da noch?
Danach.
Oh ja, 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üsst ihr mir jetzt erzählen, weil ich bin nämlich in der Zeit rübergegangen zu dem anderen Workshop.
Und ja, habe dann aber nicht wirklich zugehört, sondern gearbeitet.
Ja gut, dann...
Aber deswegen kann ich das für Wirtschaft kennen.
Aber den Topf von Haki Benita hätte ich gerne noch mehr verstanden,
wie man den Foreign Keys richtig macht.
Indizes setzen oder was hat er gesagt?
Ja, aber also die Sache an Haki Benita ist,
der ist ein DBA, ein Database Admin,
der seit 20 Jahren im Geschäft ist, der kennt alle Tricks.
Und er hat einen sehr unterhaltsamen Vortragsstil.
Sehr energetisch.
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. Er hat gesagt, ja, was fällt euch da auf? Und dann kam natürlich so, ja, da muss man 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 dann gesagt, was fällt euch denn jetzt auf? Und dann ist er noch eine Ebene runtergegangen und dann kamen schon weniger Kommentare und dann hat er gesagt, was fällt euch denn jetzt auf? Also er ist einfach ganz harmlos angefangen und dann so tief runtergegangen.
Ja, okay.
Aber als er dann aufgehört hat,
hat das Publikum an seiner Stelle weitergemacht
und hat ihm gesagt, weil er wusste noch nicht.
Und sein Fazit war dann so,
okay, das mit den Migrationen sollte man einfach lassen.
Das ist keine gute Idee, das irgendwie
nicht machen. Ja, also es ist wirklich
problematisch. Je genauer man hinguckt, desto
mehr Probleme
sieht man da auch.
Die natürlich aber auch nie, nur nicht in
allen Cases wirklich realistisch.
Bevor jetzt wieder so eintaucht,
wir müssen erstmal kurz nochmal erkennen,
Also, dass das ein interessanter Talk war, haben wir jetzt verstanden, aber
worum ging es denn jetzt eigentlich?
Also es... Willst du?
Nee, sprich du, René. Also 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
Expedition of Foreign Peace bezogen. Oder 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
Transaktionen, 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, das
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.
Ja, solltest du, also was
konkrete Dinge drin waren, wie zum Beispiel ist sowas wie,
du hast halt einen Foreign Key auf dein User-Modell
als Created Ad oder sowas an irgendeinem Modell dran
und wenn du jetzt sagst, okay, das wird jetzt schon allmählich relativ groß,
das wird eh nicht benutzt und dann nimmst du den Index weg
und dann löscht irgendein automatischer Job ab und zu mal User
und legt dann deine Datenbank lahm,
weil, naja, es gibt keinen Index mehr auf dem Ding
und dann macht das halt ein Table-Scan bei jedem User,
der gelöscht werden soll und wenn das viele sind, dann, naja, es ist halt...
Ja, auch wenn es einmal auftritt, wenn du irgendwo eine Tabelle mit Millionen rein hast.
Wenn du bei Instagram mit 500 Millionen Nutzern scheinst, dann bist du da.
Ja, genau, die müssen da schon aufpassen.
Das hat er am Ende auch gesagt.
Viele von den Sachen sind halt jetzt rausgesucht als Probleme für einen Vortrag, sonst kannst du nichts zeigen.
So für den Hausgebrauch.
Weil wenn du 10.000 TPS hast, Transaktionen pro Sekunde, ist das sicherlich ein anderes Thema, als wenn du drei Transaktionen pro Sekunde hast.
Also ich glaube, einer von den Learnings war, dass er quasi die Nutzer aware gemacht hat, dass Django sehr viele Dinge für einen mitdenkt und dass es halt Cases gibt, 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 passiert.
Ja, oder dass man auf jeden Fall immer die Queries
sich bei einer Migration zum Beispiel,
da hat er dann irgendwie eine schöne Stop-Slide,
die dann ab und zu mal kamen,
sondern erst einmal 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,
schreibt 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 nicht zustimmen, ohne das SQL gesagt zu haben.
Und das fand ich einen super Trick, weil das so ein, das ist psychologisch korrekt,
das ist kein, wir halten dich ab, das zu tun, sondern ein, hier, guck doch mal.
Absolut. Großartig.
Und was auch noch echt cool war, der hat gesagt, dass sie exzessiv die Django-Checks verwenden,
also die System-Check-Framework.
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 der Pipeline keinen Sinn, manche Einstellungen.
Aber trotzdem, dass man die da einmal so konfrontiert, dass der Pipeline grün ist, was schon mal super ist.
Und eigene Checks wirklich zu verwenden, weil 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 Django-Projekt und da kann man, glaube ich, sehr, sehr viele coole Dinge Richtung Code-Qualität machen, weil du halt den Leuten sagst, 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 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.
Kann ja die Links
wieder unten reintun.
Dann der nächste Talk.
Karl Gipsen. War gar kein technischer Talk diesmal.
Nee, hat er 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 vergessen, Kaffee getrunken.
Ja, ich würde auch zu, es ist halt ein schwieriges Thema und ich habe absolut keine Meinung dazu oder keine Ahnung davon.
Ich würde auch sagen, so ja, ja.
Ich finde es gut, dass das jemand macht.
Ja, muss man, muss man.
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 Fehlspiel draus gemacht. Das werden wir heute Abend beim 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 in den Django-Storages,
ungefähr vor einem Jahr, glaube ich, sind die Django-Storages,
ist die Settings-API leicht verändert worden.
Da gibt es statt mehreren Einzelvariablen eine Variable.
Da gab es auch eine Warnung.
Normalerweise kümmere ich mich da immer sofort drum,
aber wir hatten einen ganz, ganz merkwürdigen Bug
mit dem Thumbnail-Package, irgendwas ganz Wildes,
wo nichts mehr funktioniert hat und
ich hab dann einfach, ja, ich mach das dann später
und dann irgendwann war die Warnung halt
weg und ich so, ah, okay, dann
Ja, perfekt. Selbstgelöst, super.
Beste Probleme. Hat es halt auch nicht
ausnahmsweise halt einmal nicht, wie das
halt immer so ist. Das ist dieses Schweißer Käse Modell,
das ist halt genau einmal. Das kommt ja nachher auch noch.
Das kam vorher schon.
Genau in dem
einmal, wo man sich nicht sofort drum kümmert, wo
irgendwas komisches passiert, wo man es halt dann doch irgendwie ein bisschen
aufschiebt, in Kombination
mit Django's
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, also 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 einfach da, die sind da ja da.
Ja klar, braucht man ja.
So, weg. Ja, war sehr blöd, dann habe ich das halt im Django-Forum halt mal angesprochen, habe gesagt, hey Leute, es ist so was irgendwie dumm gelaufen, kann man nicht irgendwas 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 Systemcheck mal wieder, ein Systemcheck, wo wir einfach sagen, hey, guck mal, du verwendest hier eine Variable, die soll das eigentlich nicht mehr geben, denk mal drüber nach, ob da alles richtig ist bei dir.
Man kann ja Systemchecks aktiv disablen und so, wenn jetzt jemand der Meinung ist, er braucht jetzt die Login-URL für irgendwas anderes oder ein ganzes 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, habe 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, habe die danach nochmal manuell abgeglichen, trotzdem waren direkt ein paar Leute böse, haben gesagt, hey, chill, wir sind noch nicht fertig.
So, haben das dann gemacht.
Ich habe nochmal quasi alle Change-Logs
gemacht. Wir haben die nochmal verlinkt.
Ich habe nochmal Optimierungsideen. Hey, wenn du
ein Set verwendest statt eine Liste,
das ist nochmal einen Ticken schneller, weil das
läuft ja die ganze Zeit. Richtig
coole Lösung. Und dann kam
halt von einer Person, naja,
wir machen doch keine
deprecated Sachen im
Framework. Und dann habe ich gesagt, 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, Dango Upgrade, das ganze Tooling,
das es 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.
Und...
Wie der Diskussion von gestern, wer darf denn merchen und wer sagt
dann nein? Oder auch das, was
Carlton 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,
komm ich jetzt drauf,
safe enough, good enough for now, safe enough
to try, so, im allerschlimmsten Fall
muss man halt so ein Security, dann baut man den Check
halt wieder aus, wenn man merkt, dass es jetzt nach drei,
nach einem Major Release furchtbar ist und
alle es 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, der Gedanken war, weil ich glaube,
der erlebt sowas halt sehr, sehr oft.
Und das hat eine Person, die Handbremse quasi,
einmal so quasi schön den Stock ins Getriebe,
wo mehr oder weniger sich eine coole Dynamik
entwickelt hat, wo man dann auch wirklich sagen kann,
guck mal, das hilft vor allem Newbies halt.
Ja, man gibt halt vor allem
dem Veto sehr viel Macht.
Jeder kann sagen nein und dann stimmt es.
Und egal, wie viele Leute vorher...
Ich habe da eine ein bisschen gespaltene Meinung zu.
Ja, es ist auch schwierig, aber wenn
sowas unterwegs ist, das ist natürlich super
frustrierend, wenn du schon viel Zeit und viel Arbeit
reingesteckt hast und die Zustimmung gekriegt hast
und dann sagt einer, ach nö, du.
Also ich bin ganz auf der Meinung, so better ask for forgiveness
than for permission.
Das ist aber hier ja nicht so.
Das ist aber genau bei so einem Framework, aber vielleicht
genau falsch rum ist, weil könnte ja sein,
dass ein Flugzeug mit so einem Dango läuft
und da muss man, ja also.
Es ist auch so, dass man manche Sachen
einfach nicht wieder zurücknehmen kann, weil du kannst manche,
also es gibt da den Deprecation-Prozess,
aber es sammelt sich an.
Und das ist so ein...
Deswegen verstehe ich sehr gut die Leute, die da so die Knüppel
zwischen... Wenn der es richtig machen will, man kann es halt auch missbrauchen
und es kann halt ätzend werden und es kann politisch werden.
Ja, und es muss vor allem grün im Prozess sein.
Genau, und dann erst die Leute losrennen lassen, zwei Jahre Arbeit,
ach nee, übrigens doch nicht, ist halt ziemlich
blöd. Also ich meine, im Endeffekt haben wir halt
genau das gemacht, um auf den Tortag 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 freu mich drauf 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 gibt es
diesen schönen Spruch aus Python,
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,
dumm. Von daher gibt es jetzt Django
Removals, ganz kurz, noch einen 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 in der 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 anderen Fällen
keine Auswirkungen gehabt, die hat einfach nichts getan,
aber trotzdem interessant, das mindestens einmal
drüber laufen zu lassen und zu merken,
was man vielleicht vergessen hat. Hat mich auch von
das auch dann ein bisschen, also irgendwie einfach ein altes
Template genommen und dann mit neuem
alte Settings halt gehabt und dann
da bumm, hup, huch.
Wenn man es dann merkt, ist gut.
Jetzt hast du 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.
Hast keine Chance, wenn du nicht Carlton Gibson
heißt oder sonst was,
irgendwo Benutzer für deine Library anzukriegen.
Wenn es irgendwie so ein Nischen-Use-Case ist, also ich
habe so ein Feature, was ich gerne
in Django drin hätte, wo ich jetzt auch schon mit mehreren Leuten
drüber gesprochen habe.
Einziger Grund, warum du hier bist.
Wo ich jetzt mich mal so langsam rantasten werde
und es ist auch wirklich was ganz Kleines.
Ja, das erzähl ich nachher mal.
Da muss ich erst noch mehr politischen
guten Wirklichkeiten, bevor ich das verraten kann.
Aber, okay.
Es wäre eine sehr einfache Änderung und es wäre
auch was, was man einfach in der Bibliothek machen würde,
aber wenn ich es in der 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
den Removals. Da ist doch
ein Warnungsmechanismus drin. Warum
muss ich jetzt nochmal was machen, damit ich andere
Warnungen bekomme?
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 den Library.
Ja, okay, aber dann ist es halt
für mich. Dann ist es für mich.
Ja, könnte ich auch machen.
Entschuldigung.
Dann folgen wir die DangoCon und machen die einfach bei uns in Germany.
Gibt es ein großes Gerücht?
Ja, mal sehen.
Ja, also wir werden sehen.
Ich meine, wir Softwareentwickler sind ja, wir mögen das technische Probleme zu lösen
und jetzt hier geht es sehr viel, bei der Software Foundation ging es um Menschen und das ist doch blöd.
Ja, das ist immer dasselbe Problem.
Ich 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.
Aber mit AI sprechen ist ja noch schlimmer.
Warum? War jemand bei dem
Workshop? Nee. Nein.
Okay, schade. Dann müssen wir den jetzt auslassen.
Der Building-Unique-Voting-System.
Achso, nur eine Minute.
Klingt aber interessant.
Ja, hatte ich mich auch.
Aber die Workshops, der war halt sehr
lang und der hat dann zwei andere Talks überlegt.
Ich habe auch überlegt, wo ich hier
würde ich nicht skippen.
Das war nicht für mich so interessant.
Da bin ich erst drüber gegangen und dann habe ich gedacht, ach komm.
Genau, dann gab es doch den
How to Enjoy Debugging in Production.
Oh ja, stimmt.
Von Karen Tracy.
Der war am Anfang sehr unterhaltsam, weil sie
eine Kiste gekriegt hat,
weil sie ein bisschen kleiner ist und nicht über dieses
Pult gekommen ist.
Das Audiosetup ist dieses Mal ein bisschen schwierig,
habe ich das Gefühl. Da ist noch ein Mikrofon
da vorne. Ja, das Mastering da.
Ja, das Mastering.
Sie haben es dann ja quasi so weit aufgedreht, bis es halt
kurz vorm Rückkoppeln war. Das war immer noch
viel zu leise.
Das war in einem anderen
Konzert. Aber das war eigentlich interessant, was
sie erzählt hat. Es war super interessant.
Was hat sie eigentlich, also das Wichtigste, was sie gesagt hat
irgendwie. Es war aber auch wieder sowas
so ein, ja,
mach ich so. Ja, mach ich so.
Kenn ich. Genau.
Ja, sie sagt halt quasi,
dass man für Produktionssysteme ein Logging, ein Monitoring
extra braucht, was auch LRs kann und dass man
das halt dazu bauen muss.
Und dass man halt, also im Endeffekt, ich hab bei dem
Talk ein bisschen was anderes erwartet. Das hat, glaube ich, auch
irgendwer aus dem Publikum nachher gefragt,
weil ich dachte 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 und Monitoring verstanden, ne?
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 immer so aufhoppen,
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 dafür muss man das natürlich alles noch nicht eingestellt haben.
Und sein eigenes Laufsatz betreiben.
Die Antwort auf diese Frage, die da kam,
wie vermeidet man denn Fehler in der Produktion,
fand ich eigentlich ziemlich gut.
Weil sie hat halt gesagt, kannst du nicht.
Du musst darauf vorbereitet sein,
Fehler in der 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,
aber was... Muss ich kurz was einwerfen?
Ich habe jetzt kürzlich gelernt, es gibt
Glitchtip. Glitchtip?
Das hat die gleiche AP wie Sentry,
das heißt, man benutzt Sentry Client, aber es ist
einfacher zu hosten, weil es einfach so wie
Sentry vor fünf Jahren ist. Okay.
Für die kleinen Benutzer
ist das einfacher als Sentry. Und wenn man dann groß wird, kann man
auch auf Sentry umsteigen. Ja, cool.
Entschuldigung, jetzt...
Also was ich ganz jetzt dran fand, ist so
dieses Sidenote aus der Praxis
Zum Beispiel, jeder kennt das ja wahrscheinlich, wenn man als Entwickler fragt, was ist, wenn nichts passiert? Das kann nicht passieren. Was ist, wenn hier quasi, zum Beispiel man spricht DAPI an und zieht sich irgendwelche Daten und dann irgendwelche Nutzer haben dann eine Firma.
Ja, okay, aber das ist eine Liste, was ist, wenn jetzt zwei kommen? Ja, das passiert nicht. Ja, was, wenn doch? Nein, das passiert nicht. Und genau diese Cases sind halt meistens die, die einem dann nachher das Genick brechen, weil dann doch irgendwo 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. Je nachdem, das muss man dann mit dem Kunden oder wer auch immer das dann für jemanden bauen.
Ja, man muss rausfinden, ob es richtig ist.
Genau. Oder dass man es irgendwo vermerkt oder sowas. Aber ich glaube, 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, es 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 Zweifelsfall machst du gerade Daten kaputt, die du aufräumen musst. Das sind ja 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 es ja auch reproduzieren zum Glück,
wenn irgendwie eine Möglichkeit...
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 Metaklasse,
kann man quasi über Faker definieren, wie Daten anonymisiert werden.
Also das heißt, du hast dann quasi produktionsnahe Daten
gegen random Daten, mit denen es keinen Spaß macht zu arbeiten
und die auch meistens irgendwie nicht ins UI passen und so.
Also Django Scrubber könnt ihr euch mal anschauen auf jeden Fall.
Das ist auch so, was du für sie meintest, ne? Also so Staging erzeugen, dass von der Datenvolumen genauso groß ist.
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 typische logarithmische von der letzten Stunde, von der letzten Nacht, vom letzten Tag, von der letzten Woche, vom letzten Monat, die Dumps dann liegen, die dann 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 Sentry, aber alle personenbezogenen Daten, also per Default nämlich sind alle User-Daten raus, also man kriegt gar nichts mit.
Was natürlich schwierig ist, wenn man nicht weiß,
was ist der Kontext. Welcher User war das?
Aber das kann man relativ einfach
ein Miniscript schreiben, dass im Endeffekt alles, was man nicht in Sentry
haben möchte, rauswirft. Das heißt, vom
GDPR ist man super safe und dann hast du
halt die User-ID in Sentry, kannst damit das dann
nachstellen, hast 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, in solchen Systemen
macht man halt einfach keine Fehler.
Stimmt. Darum ist es 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.
Passt auf, was ihr 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 auch so einen Anspruch, ich weiß jetzt gar nicht mehr von wem, sagt dann so Funktionierende, Definition von Funktionierender Software, also Funktionierende Software kann man nur so nennen, wenn sie zumindest in Produktion gewesen ist und da gescheitert und man sie dann schon mal ein paar Mal verbessert hat und dann so vorher kann man nicht sagen, dass sie funktioniert, weil wahrscheinlich…
Nicht.
War, genau, ja.
Gut.
Dann gab es noch einen Vortrag und zwar 100 Million Parking Tracks.
Transactions per year with 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 damit tatsächlich, wie viele Leute sich so ein
Parkzettel umsetzen.
Hat er auch gesagt, es gibt verschiedene Sorten.
Je nachdem, wo du parkst.
Das ist das Backup von den Parkplätzen in den Niederlanden, oder?
Ja, und jetzt auch in Deutschland, hat er auch gesagt.
Ja, genau. War aber nicht auf der Karte drauf,
hätte mich jetzt interessiert. 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
Ja, 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 machen sie mit Django und das funktioniert super.
Es war also ein ETL-System, haben die gebaut?
Genau, die haben so ein ETL-System mit Django Admin gebaut.
Das fand ich so ein bisschen besonders.
Weiß ich nicht, ob ich das dann gedacht hätte.
Also, ne, du musst
Daten, musst du erst irgendwo herbekommen
und dann musst du dich transformieren und wieder
Also Extract, Transform und
Load. Genau.
Weiß ja nicht jeder. Aber es ist
trotzdem interessant, dass das mit dem
Jungle-Framework, dass das 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 hätte das auch das Gefühl, 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 Take-away,
wie weit du es treiben kannst.
Es müssen auch vier gute Leute
sein dann tatsächlich, die das gut organisieren können.
Oder drei gute Leute
und einer macht das, worauf die anderen keinen Bock haben.
Das kam auch bei diesen anderen
Talks, bei dem von Hake Benita.
Gestern 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 die doch die meiste Zeit
von einem fernhalten.
Wir haben ja vorhin über diesen Talk von Hage 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
das 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. Das war ja kein
Hexenberg, 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 erst mal
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 das funktioniert.
Wenn ich jetzt noch drei Nutzer habe, vielleicht funktioniert
das ja dann auch trotzdem.
Vielleicht.
Beim ersten geht es noch, beim zweiten...
Als Mathematiker
der größte Sprung ist eigentlich von 1 zu 2.
Alle anderen sind dann...
Das ist egal.
Man kann ja auch nur noch mit Agenten reden.
Ist das dann schon viele?
Ist der Agent dann...
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 Party abends.
Und wir können ja nicht eigentlich, oder vielleicht auch am Samstag noch eine.
Ja, schauen wir mal.
Ja, also wie auch immer, wenn ihr uns wieder hört,
bleibt uns gewogen, schaltet wieder rein.
Hallo at peisenpodcast.de für alles Feedback.
Vielen Dank, Ronny.
Das sind wir effektiv am Ende.
Danke, dass ich hier sein durfte.
Danke auch.
Ja.
Und ja, dann bis morgen.
Bis zum nächsten Mal.
Tschüss.
Ciao.
Ciao.