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 Rolli, heute alles klar.
Hallo Rollis.
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 ja gestern schon getan, die Folge ist ja tatsächlich auch pünktlich online gegangen.
Ja, fast pünktlich.
Und so nach dem Pub-Besuch ist das immer so ein bisschen schwieriger, also das Hotelzimmer wiederzufinden und dann auch irgendwie eine Visone online zu stellen.
Insofern, das ging nur so irgendwie unterschiedlich.
Nee, ich habe noch mein Fletter vermisst und dann habe ich mein Fletter gefunden, das war wahnsinnig gut.
Dann hatte ich aber meine Hotelzimmer-Eintrittskarte nicht.
Aha.
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.
Ja.
Es ist immer noch da.
Wir haben ja gestern bis zum ungefähr Mittagszeit ja erzählt, was so war.
Was war denn gestern noch Interessantes?
Oh, das muss ja nur die Zeit sein.
Das ist ja nur die Zeit.
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.
Also, ich finde, dann...
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 Barbereich.
Oh.
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 nicht damit beschäftigt hat.
Glaube ich, nicht allzu viele neue Dinge.
Kurzes Zeitnot, bevor du runtergehst.
Den Talk mittags von Sebastian hattet ihr den besprochen, weil der ist ja auch aus der Region bei uns.
Aus Völln.
Ach, den hatten wir nicht besprochen.
Nein, den hatten wir nicht besprochen.
Den haben wir gesehen.
Genau, genau.
Den haben wir nicht auch noch.
Ja, dann haben wir das doch.
Genau, da freue ich mich über 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 ob er meint, 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?
Sorry, sorry, natürlich.
Genau, also der hieß The Fine Print in Django 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 megakrassen geilen Feature,
weil man halt da sehr viele Dinge immer kommt, die einem das Leben leichter machen, wo man Code sparen kann,
irgendwelche fiesen Hex-Walkarounds ausbauen kann und hat sich dann durch die 5.x-Versionen durchgehangelt.
Da waren solche Sachen dabei, die ich noch nicht gesehen hatte.
Ja, der Code.
Der Code, da hat er das ja vorhin auch so erwähnt, dass er auf keinen Fall wieder zu 4.2 zurückgehen würde, wenn das...
Ja.
Wenn die dich verhalten lässt.
Genau.
Und genau, freut mich sehr, weil der ist jetzt auch bei, auch ein Regular beim Colony, 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 so am Abend tagt.
Wenn man nicht so Notizen hat, wie der Johannes hier vor sich.
Ja, ich war aber nicht in dem Talk, deshalb hatte ich keine Notizen zu dem Vortrag.
Da war ja was.
Ja.
!
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 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 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 scheinbar das Frameplay
auch nicht so genau gelesen.
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 es 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-Convigo, habe ich
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 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,
Content-Types, genau.
Ja, achso, 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 habe dann genau gemerkt, was Carlton
heute in seinem Vortrag, ich greife vor, aber
was er sagt, kann ich jetzt nachher
nochmal meine persönliche Erfahrung dazu
spiegeln.
Ja, da werden wir auf jeden Fall gleich nochmal eingehen. Das ist auch das Thema von gestern,
was wir dann, glaube ich, nochmal ein bisschen aufmachen, wo es um
geht, wie man denn partizipieren
kann an Django. Aber vielleicht
machen wir chronologisch weiter mit den Talks.
Ja, der nächste war Solving a Python
Mystery. Oder war
jemand bei dem Quality Workshop?
Den war ich auch nicht drin.
Nee, leider nicht.
Aber irgendwie hat es nicht
geklappt.
Aber der war gut.
Der war sehr gut. Insofern...
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.
Ja, 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, da hat man eine
eingeschränkte Shell drauf, sowas.
Aber man kann halt... Ja, also zum Beispiel, man hat
einen Docker-Container. Wie kommt man dann 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
SJS machen. Und ja, das mache ich
auch.
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 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. Und man ist einfach so,
Moment, das kann nicht sein. Das ist
einfach so weit, dass es mehrere Größen
Ordnung 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 so richtig funktioniert.
Dann, genau,
war da halt so eine Geschichte,
TCP, No-Delay kann man irgendwie
setzen, wenn man...
Genau, macht Python,
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?
TCP, No-Delay, genau.
Es ging schon sehr weit runter in den Kernel.
Das war eigentlich das Interessante, dass der halt
nicht Python debugged hat, sondern er hat eigentlich
Linux und File Handles
und Kernel Traces debugged.
Das war ganz einfach. Er meinte so, ja, von außen
solche Sachen debuggen, das ist eigentlich super einfach.
Und dann hat er ein Diagramm irgendwie
auf einer Seite gezeigt und das war halt ultra kompliziert.
Das war 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.
Der dann
im Kernel, vom Kernel, formal bewiesen
wird, dass er nichts Böses tut und dann ausgeführt werden kann.
Ja, dann.
Ja, ja.
Und jemand, den wir auch schon im Podcast hatten,
Martin, hat dafür ein Python-To
irgendwie diese Intermediate-Language-Compiler
mal geschrieben. Dann kann man das auch in Python machen.
Also, das Ding ist total gut.
Er meinte auch, das verwendet er auch häufig.
Irgendwie, wenn er nochmal tiefer gehen muss.
Ja,
ansonsten weiß ich, kann mich nicht mehr so
wirklich erinnern an alle 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 der, 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 einfach nicht beschäftigen muss.
Ja.
Mein Gedanke war, dass ich dankbar bin, dass
es so Leute gibt wie ihn, der das macht.
Meinte er auch erst halt so,
wenn er irgendwo einen 500er-Fehler sieht oder
sowas, dann, er kann nicht mehr schlafen.
Er muss das irgendwie rauskriegen.
Das geht auch ohne Unix-Debugging.
Ja.
Genau, ja. War so schön.
Danach war der Celery-Vortrag,
also der Parallelisierungs-Vortrag 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 ein,
so eine Bestätigung, dass die Sachen,
die ich rausgefunden habe, nicht ganz abwegig sind.
Ja, ja, ja. 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,
dann, 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 verarbeitet werden kann.
Und dieses Muster, das ist so was,
da, ich weiß nicht, vielleicht bin ich da
als einziger draufgekommen oder auch nicht,
ja, und dieser Vortragsmodell,
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 halt 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.
Das heißt, direkt am Anfang?
Das ist das allererste, was du machst,
bevor du irgendwas anderes machst.
Auch, ä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, also ich meine,
du änderst das nicht direkt in den nächsten,
sondern in den einen Intermittenten.
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 Prozessschritt 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,
das 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 Datenbank Transaktion,
mit einem Select for Update.
Das Select for Update und genau das hier.
Genau, das Select for Update sorgt genau dafür,
dass wenn du den,
wenn du den rausholst aus der Datenbank
mit dem Status und der ID,
das ist sozusagen der kritische Fehler.
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 du dich quasi davor,
dass du diese Race Conditions in die Datenbank rein trägst,
dass du sagst, okay, der verarbeitet jetzt was
und derweil verarbeitet jemand anders 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.
Ja, weil Idempotenz eigentlich bedeutet,
wenn du es mehrmals ausführst,
hast du das gleiche Ergebnis.
Ja.
So ein bisschen der Outcome ist das gleiche.
Was wäre der richtige Begriff dafür?
Korrekte Idempotenz.
Ja, der korrekte Begriff wäre hier irgendwie Locking oder sowas.
Du hast einen Lock da drauf und das machst 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 wichtiger, 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, das ist so.
Ich weiß nicht, was da passiert.
Das ist mir noch nie passiert.
Bei mir passiert das ständig.
Ja.
Und jetzt mal das andere Erlebnis zu haben,
ist es nicht ganz Quatsch, was du dir ausgedacht hast.
Na, 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.
Ich denke so, ha, lieber nicht.
Sowas 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, das 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,
in einem sehr Western-Centric-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 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-and-Play macht,
wie halt auch die Datenbank-Anbindung Plug-and-Plays,
wie die Caches Plug-and-Play sind,
wie mehr oder weniger eigentlich alles Plug-and-Plays.
Und da ein Authentifizierungssystem zu haben,
wäre natürlich super.
Ich glaube, die auf diesem gleichen Konzept basiert,
auf dieses Task.
Das ist im Endeffekt das Django Core,
im Endeffekt mit jedem kompatiblen Task-Runner oder Task...
Ist es Task-Runner? Ich weiß es nicht genau.
Background-Task-Backend.
Ja, Backend, genau.
Task-Backend, dann kommunizieren kann,
wenn man dann sagt, ich möchte ein 1 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 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 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 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 mal zu Celery.
Das ist ein guter Eindruck.
Fand ich auch eine interessante Idee.
Was ich daran sehr interessant fand,
ist, dass wenn man viele nutzen...
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.
Ja, aber...
Aber das wird immer rot umrandet und da...
Das heißt, die meisten Leute nutzen halt dann Redis oder Revit im Queue
und ein Derivate von Redis ist das bekannteste.
Viele Leute nutzen Redis.
Und dann gibt es halt diesen Disclaimer auf der Webseite,
dass wenn man halt Schedule...
Also wenn man quasi Tasks...
in die Zukunft plant,
dass es damit Redis-Issues gibt.
Das ist da seit...
Also uns ist das glaube ich 2018 auf die Nase gefallen.
Und unser...
Also wir haben ja immer gesagt, okay,
dann nutzen wir Revit im Queue, 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 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 dann in einem Lightning Talk erst einmal,
meinte er so,
ja, ja, ihr denkt, ihr nutzt die nicht.
Aber in dem Moment, wo ein Retry kommt,
nutzt ihr 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 Hellraise verwenden.
Ja, Ivar Skalvans ist der Name.
Ja, ja, also den Namen mal gesagt.
Ich verstehe auch nicht so genau,
warum mit dem Scheduler,
das funktioniert immer nicht so, wie man das richtig will.
Und das Package heißt übrigens Django-Task-Queue,
also wie der Buchstabe.
Das heißt, irgendwer mal Spaß hat, das auszuprobieren.
Ja, es gibt leider so ein bisschen viele Django-Task-Sachen,
die alle so ganz ernst sind.
Ja, kann ich verlinken, aus 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.
Logs, Shells, Caches and other strange words.
Von einem Dortmunder, das fand ich auch interessant.
Ja, das ist ja auch relativ nah bei uns dran,
aber noch nie gehört.
Nee, ist ungeheuer weit weg, finde ich.
Ja, ja, gut.
Ja, Hörertreffen in Stuttgart.
Ja.
Die machen sich jetzt dafür ab.
Genau, der Vortrag.
Wir haben übrigens ganz kurz zum Hörertreffen,
schon uns entschieden für das Wort.
Er kam ja immer noch um.
Unsere.
Ja, da ging es dann schon so ein bisschen ins Abendprogramm 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,
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-Computer,
dass das nicht stimmt,
also dass das nicht die Ursache davon ist.
Das habe ich schon oft rum erzählt.
Ja.
Das ist auch ein schönes Bild.
Ja, aber das musst du mir noch mal erzählen.
Ich habe den Tag nämlich verpasst.
Warum stimmt das nicht?
Also es gibt diesen Eintrag von dieser Computermitarbeiter,
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.
Und als er 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.
Ach so, die kleinen Käfer.
Und dann hat sie gesagt, okay,
jetzt haben wir wirklich einen echten Käfer.
Genau.
Ja, die Mutter.
Das fand ich aber auch sehr interessant,
dieses Zitat, weil das ist ja auch ein Gefühl,
was man so kennt.
Ja.
Dass man einmal so einen Inspirationsschub hat
und dann stellt sich da die Realität in den Weg.
Ja.
Und du weißt aber eigentlich erst,
wenn du diese ganze schmutzige Arbeit gemacht hast,
ob es ein Erfolg oder ein Misserfolg ist.
Ja.
Ja, das ist echt eine Idee.
Dir 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.
Ja.
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 das noch nicht geschafft habt,
habt ihr es noch nicht geschafft.
Ja.
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 haben wir schon.
Sehr gut.
Morgen ist er auch schon voll, habe ich gehört.
Auch schon voll.
Heide ne.
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 ja, das aus Gründen nicht funktioniert hat.
Und so wegen, the circle 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
doch einfach Open Source machen könnten
und sie es trotzdem voll zahlen.
Was am Anfang für ein paar Gehoffene
oben Augenbrauen geführt hat, weil, warum Open Source?
Hä, wir zahlen doch auch wieder.
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.
Ja, vor allem auch, weil wir ansonsten
das halt irgendwie in den Monolithen reingewurschtelt 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.
Ja.
Nein, genau.
Man kann ja auch schlecht maintainen.
Ich maintaine Sachen aber teilweise sehr, sehr schlecht.
Nein, aber vor allem das Schöne an der Geschichte,
dass man sich nicht so weit fortgeschritten hat,
ist, dass wir jetzt endgültige Sprachver dialogieren.
endgültige Sprachver dialogieren.
geschrieben habe und es halt wirklich auch
im Endeffekt eine wirkliche Win-Win-Situation war,
weil auch wirklich die Entkoppelung auch dann da war,
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 Success-Story
verkaufen und ein bisschen Werbung zu.
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.
Es gibt nämlich
Mig Zero und Migration Zero Django
und ich glaube, Migration Zero ohne Django.
Ja, meinst du,
ich habe einen Artikel geschrieben, ich habe in Blogposts
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
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 ziert jetzt 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 Aus, 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 Circular Dependencies und wenn du squaschen 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 dem 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
haben wir alle schon ausgemacht, 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 im Endeffekt
habe, manchmal 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
Abteilen 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, der
Apply Cache, ja, 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 Atom quasi
an- und ausstellen, also du sagst, okay, ich weiß, es kommt
ein Deployment, das nächste Deployment, das ist,
mach den Haken an, dann macht dir 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, ähm, 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?
Ähm, 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 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, ähm,
von daher versuchen wir jetzt in den neuen Projekten
eher über Profile zu gehen.
Also Profile ist für euch ein eigenes Modell, eine eigene
Tabelle?
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 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,
ähm, dann,
das fällt mir gerade kein Beispiel mehr, zum Beispiel,
wenn du sagst, ich habe irgendwelche Konfigurationen, die ich
machen kann in meiner Applikation, gibt es vielleicht ein User-
Konfigurationsprofil und versuch
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 Jackson
Junior, der ins Projekt kommt, der muss halt 50 Felder
verstehen und nicht nur drei.
Das mit der 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-Rebuilding, deswegen ist der gar nicht.
Also ich sage mal so, ich versuche die,
ich nutze die, aber ich versuche da dreimal
drüber nachzudenken, ob ich sie wirklich nutzen möchte und
wenn ich zum Beispiel so eine 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 Firstname brauche, ich brauche keinen Lastname,
ich brauche keinen... Ich habe auch alles gestrichen,
nur E-Mail. Ja, genau,
einfach nur E-Mail und Passwort und das ist eigentlich
für die meisten Sachen reicht das ja schon.
Aber das spricht ja tatsächlich
meinem eigentlich gar nicht. Ja, genau,
das ist eigentlich das Gleiche.
Vielleicht sogar noch ein logischer weiterer Schritt.
Ja, aber halt mit Aufwand verbunden.
Ja, 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,
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.
Ich finde das zum Beispiel super,
dieses Toolbox-Package, das wir haben.
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...
Ich räume da auch regelmäßig auf.
Also einfach, wenn ich dann sage, okay, jetzt bin ich zu einem Zeitpunkt gekommen,
wo das nicht mehr relevant ist oder
habe einfach Sachen aktiv rausgezogen.
Also das Body Express Package, von dem ich vorhin
am Anfang gesprochen habe, das war auch mal Teil
davon. Da habe ich auch 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 so früh überlassen.
Auch ich.
Und das seit 9 Uhr nach
Lukala. 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.
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 Django.
Es gab auch Kuchen.
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.
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.
Für Kinder mit Kindern ist das eigentlich so.
Ich kam halt aus der Stadt
und die Busse fahren so mittel.
Ja, okay, gut.
Das ist natürlich...
Wir sind ja alle hier im Hotel.
Da ist es natürlich einfacher.
Ja.
Ich habe jemanden gesehen, der mit Bade...
Badelatschen die ganze Zeit.
Da dachte ich mir so, oh, warum bin ich da nicht drauf gekommen?
Die Schuhe an.
Ja, ich habe mich auch nicht gedacht.
Ich wollte eigentlich gerade eben nochmal in Stim 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, doch alles auf dem Boden.
Power-Mode.
Ja, das ist auch eine Frage.
Also, ich passe immerhin rein.
Ich habe ja nämlich meinen eigenen Bademantel.
Das haben wahrscheinlich auch nicht so viele.
Okay, also das Django-Sachverfahren 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...
Wie viel Zeit man mit so Dingen verbringen kann.
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 so allem.
Ja.
Ja, dann muss man nochmal reden.
Jeder darf auch was dazu sagen.
Und dann wird dem auch zugehört.
Und dann...
Also, sehr corporate.
Ja.
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, sage ich mal, im Mainstream.
Oh, im Mainstream.
Im Mainhall.
Nee, es heißt ja Mainhall, ich meine.
Hab ich...
Gab es den?
Hab 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.
Ach so, hat der Jochen den Lightning Talk vom Johannes vorher schon gehört?
Ich habe ihm das vorher kurz gezeigt.
Das war nur der Vulkanier Mind...
Mindgrab.
Genau, das war auch eine sehr schöne...
War sehr unterhaltsam, dieser Vortrag.
War auch nicht lang.
Er hat viele Sachen gesagt.
Und viele von den Geschichten kennt man ja schon so ein bisschen.
Ja, ja.
Hast du 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.
Ja, das mit der Mars-Mission mit demetrischen Systemen.
Ja, ja.
Vielleicht gehen wir nochmal kurz darauf ein.
Also ein Bagger ist natürlich in den Flugzeug abgestürzt.
Nicht so gut, weil...
Nee, es sind zwei sogar.
Es sind zwei abgestürzt.
Boing.
Wo was passiert ist.
So ein System eingebaut hat, das 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 abgeschickt gekriegt.
Und vor allem, dieses System ist gekoppelt an den Steuerknüppel.
Das heißt, die haben versucht an den 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 du halt gegen die Maschine kämpfen musst.
Und die Maschine in dem Moment will dich umbringen.
Wie ist gesagt.
Und dann gewinnst du auch noch.
Das ist hart.
Das ist echt hart.
Und dann klappt es.
Oh je.
Und dann, genau.
Nachdem diese beiden Flugzeuge abstürzt waren, ist ja auch die gesamte Flotte einfach stillgelegt worden.
Für den Moment, bis da einmal eine neue Zertifikation durch war.
Ja, die die haben.
Ja.
Also es war eine wirklich schöne Aufstellung von Sachen.
Genau.
Auf der Mars-Mission ist vielleicht auch noch interessant.
Ah ja, Mars-Mission.
Ja, weil es dann...
Klassischer Fall.
Kein Backup zwischen Umrechnung, zwischen metrischen und...
Nur ein kleiner Fall.
Das war das andere System.
Genau.
Das ist ein Imperiales System.
Imperiales.
Ja.
Und halt...
Genau.
Das eine hat eben halt den Zoll gerechnet und das andere hat den Millimeter gerechnet.
Empire Strikes Back.
Ja.
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.
Ja, aber...
Und es ist keine Gelegenheit, nicht jedes Schiff und jeden Soldaten nochmal hervorzuheben,
wie besonders das war, gegen England gewonnen zu haben.
Aber da mit Händen und Füßen am imperialen System bei den Einheiten festzuhalten.
Ja.
Am Ende gewinnt der König doch.
Ja, das war auch eine tragische Sache.
Ja.
Das ist dieses...
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.
Klabum.
Andererseits, 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.
Ja, und dann die anderen Geschichten.
Da gibt es ja viele so Geschichten.
Ich finde es 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
ja betrifft und das ist tatsächlich, ah ja, auch immer eine sehr hübsche Fehler, also
dass Leute Excel-Sheets halt für alles möglich 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 auf Excel dann das nachbauen.
Bitte?
Man kann das dann auch nachbauen.
Ja, aber das wird...
Ja, hast du schon mal gesehen, dass jemand Excel-Sheets in quasi...
Habt ihr keine Unitests, aber in Excel-Sheets...
Ja, oder Unitests 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 Leitung schon ein paar Jahre nachgebaut, das war eine ganz tolle Erfahrung.
Ja.
Ach so, du hast es 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...
Hups.
Falsch.
Addiert statt...
Addiert.
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, aber...
Er denkt halt so...
Portier für jedes Feind-Wochenende.
Ja, sechs Milliarden unter Freunden kommen.
Ja.
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.
Perfekt.
Ja.
Ja, was gab es denn da noch?
Danach.
Oh ja, das war cool.
Danach war so ein bisschen, für mich bisher, das Highlight des Tages.
Das Highlight der Woche bisher.
Haki Benita.
Genau.
How to get foreign keys horribly wrong.
Ja, das müssen wir jetzt erzählen, weil ich bin nämlich in der Zeit rübergegangen zu dem anderen Workshop
und habe dann aber nicht wirklich zugehört, sondern gearbeitet.
Ja, gut.
Aber deswegen kann ich das Workshop kennen.
Denn aber den Topfer 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 das 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 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 dann hat er gesagt, was fällt euch denn jetzt auf?
Und dann ist er noch eine Ebene runtergegangen.
Und dann kamen schon weniger Kommentare.
Und er hat gesagt, was fällt euch denn jetzt auf?
Also er ist einfach ganz harmlos angefangen und dann so tief runtergegangen.
Ja, okay.
Ja, aber auch, als er dann aufgehört hat, hat das Publikum an seiner Stelle weitergemacht
und hat ihm gesagt, ja, das ist ein DBA.
Ja, okay.
Und er hat dann gesagt, ja, das muss man nicht.
Und sein Fazit war dann so, okay, das mit den Migrationen sollte man einfach lassen.
Das ist keine gute Idee.
Das muss man irgendwie nicht machen.
Ja, also es ist wirklich, es ist halt problematisch.
Je genauer man hinguckt, desto mehr Probleme sieht man da auch.
Die natürlich aber auch nie nur nicht in allen Cases wirklich relevant sind.
Vorher wieder so Eintauchter.
Wir müssen erstmal kurz nochmal erklären.
Also, dass das ein interessanter Talk war, haben wir jetzt verstanden.
Aber womit ging es denn jetzt eigentlich?
Also es...
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 dann ging es halt darum, was kann man daran verbessern.
Und dann hat sich halt Ex-Videoforeign-Keys 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, 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 viele Migrations, Migration-Anordnungen, was man damit noch anders machen kann, also indem man die einfach auseinanderzieht, Atomare Transaktionen, 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 auch immer...
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 ein 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ß, ich mach das...
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.
Ja.
hast. Wenn du bei Instagram mit 500 Millionen
Nutzer anscheinend bist. 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.
Ja, oder dass man auf jeden Fall immer
die Queries, nicht bei einer Migration zum Beispiel,
er hatte dann irgendwie eine schöne Stop-Slide,
die dann ab und zu mal kamen,
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.
Und 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 gar nicht, du kannst nicht zustimmen,
ohne das SQL gesagt zu haben. Und das fand ich
einen super Trick.
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-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 einfach 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 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 Django-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 bei dem Vigo-Talk,
deine Architektur oder Code-Qualität
ist so gut wie dein Tooling, das du hast.
Ohne Tooling degradet
alles sofort.
Also war nach Fistball
viele coole Sachen drin. Haki Benita ist
immer gut.
Kann ja die Links wieder unten reintun.
Dann der nächste Talk.
Keinen Gipsen.
War gar kein technischer Talk diesmal.
Nee, hat er auch am Anfang
so scherzhaft gesagt.
Nächstes Mal wieder Techno-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
oder keine Ahnung davon.
Ich würde auch sagen, so, ja, ja.
Ich finde es gut, dass das jemand macht.
Ja.
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 Prächspiel 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 jetzt ermüdet ist,
da kann ich doch einen schönen Bogen spannen zu meinem Eingangsthema,
ähm, ich habe vor einem Jahr, ähm,
äh, ist, sind in den Django-Storages,
ungefähr vor einem Jahr, glaube ich, sind die Django-Storages,
ist die, die, äh, die Settings-API leicht verändert worden.
Da gibt es irgendwie statt mehreren Einzelvariablen,
gibt es eine Variable.
Da gab es auch eine, ähm, eine Warnung.
Und normalerweise kümmere ich mich da immer sofort drum,
aber wir hatten einen ganz, ganz merkwürdigen Bug
mit dem, äh, Sorrel-Thumbnail-Package,
irgendwas ganz Wildes, wo nichts mehr funktioniert hat.
Und ich habe dann einfach gesagt, ich mache das dann später.
Und dann irgendwann war die Warnung halt weg.
Und ich so, ah, okay, dann...
Ja, perfekt.
Okay.
So, ähm, hat es halt auch nicht,
ausnahmsweise halt einmal nicht,
auch wie das halt immer so ist.
Das ist dieses Schweizer Käse-Modell,
das ist halt genau einmal...
Das kommt ja nachher auch, ne?
Genau.
Das kam vorher schon, im Wartest-Übertrag.
Ähm, 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,
ähm, in Kombination mit, äh, Django-Storages,
was wir für S3, also für Datentransfer nach S3,
verwenden, ähm, war eine Plattform,
ähm, an der ich gearbeitet habe.
Und, ähm, genau in dem Zeitfenster,
wo wir dann quasi das Django-Upgedated haben,
ähm, wo dann quasi diese Storage war,
also dass die Deprecation quasi aktiv wurde,
ähm, 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-Storages das nicht gemerkt.
Django dachte, das Feld ist nicht mehr da
und die Sachen sind einfach nicht mehr da.
Die sind alle in Nirvana gelandet.
Das war ärgerlich.
Ähm.
Eine schöne, schöne Übertreibung, die du hier erwählst.
Ärgerlich.
Ja.
Und, äh, war natürlich auch etwas schwierig,
dann den Leuten zu erklären,
äh, sorry, bitte alles nochmal.
Teilweise waren die Sachen natürlich einfach da.
Nee, die sind da ja da, die...
Ja, klar, braucht man ja.
So, weg.
Ja, war sehr blöd.
Dann habe ich das halt im Django-Forum halt mal angesprochen,
hab gesagt, hey Leute, ist das sowas irgendwie dumm gelaufen,
kann man nicht mehr was tun.
Und dann hat sich da so eine Diskussion ergeben,
dass man ja vielleicht, weil,
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 soll das eigentlich nicht mehr geben.
Denk mal drüber nach, ob du die wirklich noch,
ob da, ob da alles richtig ist bei dir.
Ne, 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 ganzer 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,
ähm, hab mir,
ähm, sehr zum Ärger von manchen Leuten
eine initiale Liste von, von, äh,
von GPT generieren lassen,
weil ich dachte, ich,
damit ich erstmal was hab zum Testen,
ob es überhaupt funktioniert,
hab die danach nochmal manuell abgeglichen,
trotzdem waren direkt ein paar Leute böse,
hab dann gesagt, hey, chill,
wir sind noch nicht fertig.
Dieser Oni bist du, was du einfach.
So, haben das dann gemacht,
ich hab nochmal quasi alle,
alle Change-Logs gemacht,
wir haben die nochmal verlinkt,
ähm, ich hab nochmal Optimierungsideen,
hey, wenn du ein Set verwendest,
statt einem, statt einer Liste,
das ist nochmal einen Ticken schneller,
weil das läuft ja die ganze Zeit,
du hast ja noch mal ein paar,
du, du, du, du,
richtig coole Lösung,
und dann kam halt von einer Person,
naja, aber wir haben doch,
wir machen doch keine,
keine Deprecated-Sachen im,
im, im, im Framework,
und dann hab ich so,
ja, aber die Leute haben doch gesagt,
ich bin nicht der Einzige,
der 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är's mir ja nicht passiert,
und ich bin ja aware,
oh, Danko, upgrade die ganze,
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,
zehn 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, ähm,
wie der, wie der Diskussion von gestern,
wer darf denn mergen,
und wer sagt dann nein?
Genau, oder auch das,
was Carlton gesagt hat,
dass Konsens gesucht wird,
und das auch genau das bedeutet.
Genau, das ist ja genau das,
und ich glaube,
dass er hat,
also selbst Carlton war ja auch
in dem, 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, alle Leute sagen,
okay, das können wir machen,
wie dieser schöne Spruch,
ähm,
komm ich jetzt drauf,
äh, safe enough,
good enough for now,
safe enough to try,
so, im allerschlimmsten Fall
muss man halt so ein Security,
das 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, ähm,
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.
Ja.
Und das hat eine Person,
die Handbremse quasi,
ne, einmal so quasi
schönen 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, ne,
und.
Ja, man gibt halt vor allem dem Veto
sehr viel Macht,
ja, man gibt dem,
jeder kann sagen nein,
und dann stimmt's,
und egal wie viele Leute vorher,
ein bisschen gespaltenem Meinung zu.
Ja, es ist auch schwierig,
aber,
aber wenn sowas unterwegs ist,
das ist natürlich super frustrierend,
wenn man schon viel Zeit
und viel Arbeit reingesteckt hat,
und die Frage ist jetzt wobei,
dann sagt einer,
ach, ne, du.
Also ich bin ganz auf der Meinung,
so better ask for forgiveness
than for permission.
Mhm.
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,
es ist auch so,
dass man manche Sachen
einfach nicht wieder zurücknehmen kann,
weil du kannst manche,
also es gibt ja den
Depokations-Rotest,
aber,
das ist so ein,
einfach so mit dem Hedge,
das sammelt sich an.
Ähm,
und das ist so ein,
deswegen verstehe ich sehr gut
die Leute,
die da so die Knüppel zwischen,
wenn der es richtig machen,
also man kann es halt auch missbrauchen,
und das kann halt ätzend werden,
und das muss vor allem
früh im Prozess sein.
Genau,
und dann erst die Leute losrennen lassen,
zwei Jahre Arbeit,
ist halt,
ach, ne, übrigens doch nicht,
ist halt ziemlich blöd.
Also ich meine,
im Endeffekt haben wir halt
genau das gemacht,
um auf den Tor-Tag wieder zu kommen,
was,
äh,
was Carlton halt auch vorgeschlagen hat,
der sagt,
das Ecosystem von Django
ist halt im Endeffekt
einer der Haupt-USBs.
Ich hab's schon wieder gesagt.
Ich freu dich drauf hingewiesen.
Ähm,
und, äh,
die, ähm,
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 diese,
gibt es diesen schönen Spruch aus Python,
äh,
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 halt
etwas viel zu langsam sind,
um,
von daher gibt es jetzt
Django Removal.
Django Removal,
ganz kurz,
noch ein kurz,
also wer sich dafür interessiert,
das ist, äh,
sehr, sehr klein
und tut nur was
auf dem Development Server,
kann man theoretisch,
wenn man das möchte,
auch als Development,
äh,
Dependence installieren,
dann läuft's ja nicht in der Pipeline,
und dann kann man quasi,
wenn man,
vor allem für alte Projekte,
äh,
Fun Fact,
in jedem einzelnen alten Projekt,
also alt,
sag ich mal,
2018 und davor,
hab ich mindestens eine Variable gefunden,
die nicht mehr da drin sein sollen,
hat in allen anderen Fällen
keine Auswirkung gehabt,
die hat einfach nichts getan,
aber trotzdem interessant,
das mindestens einmal drüber laufen zu lassen
und zu merken,
äh,
was man vielleicht vergessen hat.
Hat mich auch schon,
das ist auch schon ein bisschen,
also irgendwie einfach
ein altes Template genommen
und dann mit neuem Projekt angefangen,
alte, äh,
Settings halt drin gehabt
und dann,
ja, bumm,
äh, hup, huch,
also,
wenn man's dann merkt,
ist gut,
jetzt habt ihr die Lösung.
Ja,
das,
das Problem,
was ich hab mit dem,
mit der Library-Lösung,
ist Visibility.
Ja,
weil niemand erfährt davon,
dass es das gibt, ja.
Ja.
Du hast keine Chance,
wenn du nicht, äh,
Carlton Gibson heißt,
oder sonst was,
äh,
irgendwo Benutzer
für deine Library anzukriegen.
Ja.
Wenn's irgendwie so ein
Nischen-Use-Case ist,
also ich hab so ein,
so ein Feature,
was ich gerne in Django drin hätte,
wo ich jetzt auch schon
mit mehreren Leuten
drüber gesprochen hab, äh,
wo ich mich,
weil so langsam rantasten werde
und es ist auch wirklich
was ganz Kleines.
Sächtest du das denn in Django?
Ja,
das erzähl ich nachher mal.
Da muss ich erst mal
mehr politischen,
guten Widerspruch,
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's in der Bibliothek
machen würde,
wäre es unsichtbar.
Niemand würde das finden.
Ja.
Weil es eine Funktionalität
von Django,
die in Django Core drin ist,
erweitert.
Mhm.
Genauso wie bei
Dying Removals, 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,
ja,
dass es Dinge gibt,
die man mit wenig Aufwand
machen könnte,
die halt Django erweitern
und die Antwort ist,
tu's in der Library.
Ja, okay,
aber dann ist es halt für mich.
Dann ist es für mich.
Ja, könnte ich auch machen.
Entschuldigung.
Darüber sprechen wir dann morgen.
Das nächste Mal
habe ich gehört,
folgen wir die Django-Con
und machen die einfach
bei uns in Germany.
Gibt's ein großes Gerücht?
Ja, hm,
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's
sehr viel,
bei Parten ging's darum,
bei der Django Software Foundation
ging's um Menschen
und das ist
auch blöd.
Ja, das ist immer
das selbe Problem.
Ich bin noch nicht
Softwareentwickler geworden,
um mit Menschen zu tun zu haben
und jetzt muss ich
mit Menschen sprechen.
Schrecklich.
Ich, ähm,
ich könnte da so eine
Coaching-AI fragen.
Ja, aber mit AI sprechen
ist ja noch schleller.
Warum?
Äh, was,
war jemand bei dem Workshop?
Nee.
Nein.
Hm, hm,
okay, schade,
dann müssen wir den jetzt auslassen.
Ein Unique Voting System.
Ach so, äh,
nur eine Minute.
Hm, ja.
Okay.
Klingt aber interessant.
Ja, ja,
da hatte ich mich auch,
aber die,
der war halt sehr lang
und der hat dann
zwei andere Talks
überlegt.
Genau.
Ja.
Ich habe auch überlegt,
wo ich gehe,
genau,
und dann,
ich habe mich nicht so
interessant,
irgendwie erst drüber gegangen,
aber dann habe ich gedacht,
ach, komm.
Ah.
Ja.
Äh, genau,
dann gab es noch den
How to enjoy debugging
in production.
Oh ja, stimmt.
Von der,
von Karen Tracy.
Genau.
Der war am Anfang
sehr unterhaltsam,
weil sie nicht,
weil sie eine Kiste,
weil sie eine Kiste gekriegt hat,
weil sie ein bisschen kleiner ist
und nicht über dieses Pult
gekommen ist.
Ja.
Das Audio-Setup ist dieses Mal
ein bisschen schwierig,
habe ich das Gefühl.
Da ist noch ein Mikrofon
da vorne.
Ja, das Mastering war,
ja.
Ja, das Mastering.
Sie haben es dann ja
quasi so weit aufgedreht,
bis es halt kurz
vor dem Rückkoppeln war.
Das war immer noch
viel zu leise.
Ja.
Das war in einer anderen
Konstanz.
Aber das war eigentlich
interessant,
was sie erzählt hat.
Es war super interessant.
Ja.
Was hat sie eigentlich,
also das Wichtigste,
was sie gesagt hat,
irgendwie.
Es war aber auch wieder
sowas,
so ein,
ja, mache ich so.
Ja, mache ich so.
Ja, kenne ich.
Genau.
Also,
ja,
man sagt halt quasi,
dass man für Produktionssysteme
ein Logging
und ein Monitoring extra braucht,
was auch LRs kann.
Ja.
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 debugt.
Und ich glaube,
ein Großteil ging halt davon,
wie man eigentlich vermeidet,
dass es halt kommt,
was ja auch genau
der richtige Weg ist.
Ja, ja, gut.
Aber ich glaube,
sie meinte,
also Debugging hat sie tatsächlich
unter Logging und 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 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 so.
Und dafür muss man das natürlich
alles ordentlich eingestellt haben.
Ja, klar.
Und sein eigenes
Arbeitsplatz betreiben.
Die Antwort auf diese Frage,
die da kam,
wie vermeidet man denn
Fehler in Produktion,
fand ich eigentlich ziemlich gut,
weil sie hat halt gesagt,
kannst du nicht.
Du musst drauf 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,
ist 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 Glitchtip.
Glitchtip?
Das benutzt,
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 noch aus Sentry umsteigen.
Ja, cool.
Ja, Entschuldigung,
jetzt.
Also, was ich ganz interessant fand,
ist so diese,
diese Side Notes aus der Praxis,
zum Beispiel,
so diese,
jeder kennt das ja wahrscheinlich,
wenn man,
wenn man als Entwickler fragt,
was ist,
wenn nichts passiert?
Das kann nicht passieren.
So, was ist,
wenn hier quasi,
zum Beispiel,
man spricht DAPI an
und zieht sich irgendwelche Daten
und dann irgendwelche Nutzer
haben dann eine Firma.
So, 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 danach halt das Genick brechen,
weil dann halt 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 man halt dann
mit dem Kunden
oder wer auch immer
das dann für jemanden
ausfinden,
ob es richtig ist.
Genau.
Oder dass man es irgendwo
vermerkt oder sowas.
Ja, 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,
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 Zweifel,
dann machst du,
dass du gerade
Datenkaputte aufräumen musst,
sodass wir die Sachen
dies ä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
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 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 zu 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 sie meintest, ne?
Also so Staging erzeugen,
das von der Datenvolume
genauso groß ist wie...
Genau, 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,
so in den größeren Projekten
ein S3-Bucket,
wo dann halt diese quasi,
also 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 Grund.
Welcher User war das?
So, aber das kann man relativ einfach
ein Miniscript schreiben,
dass im Endeffekt alles,
was man nicht in Sentry haben möchte,
raus wird.
Das heißt,
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, ein solches System
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 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 auch so einen Anspruch,
ich weiß jetzt gar nicht mehr von wem,
sagt dann so,
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.
So vorher kann man nicht sagen,
dass sie funktioniert,
weil wahrscheinlich,
äh,
nicht,
war,
genau,
ja.
Muss man erst nochmal da durch.
Dann gab es noch einen Vortrag
und zwar
100 Million Parking 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 paar
Parktransaktionen
Ja, genau.
Hat er ja auch gesagt,
gibt es verschiedene Sorten,
je nachdem wo du parkst,
den die Daten schiebst.
Das ist das Bekenntnis
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 du was ähnliches
oder sogar den gleichen Service.
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 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, ne?
Ja.
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 sie 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 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, oder?
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 Tops,
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 Hake 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,
auch unkompliziert.
Ja.
Das 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.
Ja.
Und das ist so ein bisschen
eine schöne Bestätigung,
dass man eigentlich
sich erstmal keine Sorgen
darü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.
Und wenn ich dann
drei Nutzer habe,
vielleicht funktioniert
das ja dann auch trotzdem.
Ja, das,
vielleicht.
Beim ersten geht es noch.
Beim zweiten,
na.
Als Mathematiker,
der größte Sprung
ist eigentlich von eins zu zwei.
Alle anderen sind dann,
das ist egal.
Ja,
dann sind wir bei,
man kann ja auch nur noch
mit Agenten reden.
Ja.
Ist das dann schon viele?
Ist der Agent,
ist dann,
das ist ja ein anderes Thema.
Anderes Thema.
Genau,
das ist ein anderes Thema.
Das war es.
Jetzt ist gerade Mittagspause.
Ja.
Es war Mittagspause,
wir haben schon was verpasst.
Ja.
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
noch eine.
Ja,
schauen wir mal.
Ja,
also wie auch immer,
wenn ihr uns wieder hört,
bleibt uns gewogen,
schaltet wieder rein.
Hallo,
erpeißenpodcast.de
für alles Feedback.
Vielen Dank,
Sonny.
Wir sind jetzt effektiv am Ende.
Ja,
danke.
Wir machen heute Abend
das nicht.
Danke auch.
Ja.
Und ja,
dann bis morgen.
Bis zum nächsten Mal.
Tschüss.
Ciao.