Transcript: Live von der DjangoCon Europe 2025 in Dublin - Tag 2

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.

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.

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.

Ja.

Ja.

Ja.

Ja.

Ja.

Ja.

Ja.

Ja.

Ja.

Ja.

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.

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.

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,

dass man sich nicht so weit fortgeschritten hat,

ist, dass wir jetzt endgültige Sprachver dialogieren.

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.

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.

Ja.

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.

Addiert.

Addiert.

Addiert.

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.

Ja, okay.

Ja, okay.

Ja, okay.

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.

Ja.

Ja.

Ja.

Ja.

Ja.

Ja.

Ja.

Ja.

Ja.

Ja.

Ja.

Ja.

Ja.

Ja.

Ja.

Ja.

Ja.

Ja.

Ja.

Ja.

Ja.

Ja.

Ja.

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,

wo ich mich,

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,