Hallo liebe Hörerinnen und Hörer, willkommen zum Python-Podcast, heute in der Episode 2 to the Power of 5, Episode 32, heute geht es vor allen Dingen um DjangoCon und so ein paar Sachen drumherum, Jochen hat einen kleinen Stream aufgemacht und sowas und ja, heute ist wieder Johannes dabei, hi Johannes.
Hallihallo, hallo, hi Jochen, hallo, ich bin der Dominik, hallo, genau, ja, wollen wir direkt mit der DjangoCon starten oder haben wir noch andere News, die da irgendwie reingehören?
Ja, Django-Con sind die wichtigsten News.
Okay, also die paar News, die ich habe, die kann ich auch direkt, weil ich habe nicht so viel verfolgt, weil es passieren die ganze Zeit irgendwelche Dinge und ich habe keine Zeit mehr irgendwas zu machen.
Ja, Entschuldigung übrigens auch an der Stelle, dass wir euch so lange haben warten lassen, diese neue Episode, aber das war gerade absolut drunter und drüber im Privatleben, da musste man ja kurz ein bisschen warten.
Nee, dann.
Wir haben euch aber nicht vergessen, wir machen auch weiter.
Genau, genau. Ja, dann können wir eigentlich direkt einsteigen.
Ja, genau.
Waren wir alle auf der Django-Con?
Nein, ich nicht.
Achso, dann können wir dir ja davon erzählen.
Genau, ich wollte gerade sagen, es war mir zu virtuell
und ich bin gespannt, was da losgeht.
Ich habe gehört, es ging los mit Programming for Pleasure.
Oder wollt ihr erstmal generell was sagen?
Ja, das ist auch gleich das erste große Highlight, würde ich sagen.
Ja, das war auch so ein Ding, was mich total überrascht hat.
Also mit so einem Talk hätte ich gar nicht gerechnet.
Vielleicht mal kurz am Anfang, worum es ging.
Jemand hat erzählt, die meisten Menschen programmieren aus Spaß,
weil es irgendwie cool ist.
Aber das ist gar nicht so toll.
Ja, das ist so ein bisschen die Hypothese davon, genau.
Also Daniele Prosida hat diesen Talk gehalten,
der erste Talk in der ganzen Konferenz
und war direkt großartig.
Ich hatte Daniele Prosida 2018 in Heidelberg schon mal gesehen
und auch da hat er einen großartigen Talk gehalten.
Auch völlig untechnisch, aber sehr relevant.
Und die Hypothese, die er da aufstellt,
ist halt, dass Programmierer Spaß an ihrem Job
haben und
dass das gut für die Programmierer ist, aber
schlecht für alle anderen, weil dann machen wir das
nämlich zum Spaß und nicht für das
Ergebnis.
Das heißt, für uns
als Softwareentwickler ist es viel
wichtiger, dass wir möglichst
viel und möglichst lange programmieren können
und was dann dabei
rauskommt, ist gar nicht so wichtig, weil das
ist nicht das, woran wir Interesse haben.
Für mich als Chef ist das jetzt total Mist, das heißt, ich muss
jetzt irgendwie versuchen, euch anders zu erziehen.
Also tatsächlich, ich
fühlte mich, als ich den Vortrag gehört habe
und ich dachte so, wir gingen ja auch schon so los
irgendwie so, ja, programmieren, voll gut
irgendwie total bessere
Jeder macht das ja auch selber zu Hause
Zu Hause noch und ja, da dachte ich so, ja, ja
voll gut
und dann kam irgendwann der Punkt, wo das dann
umschlug und ich so, ja, kann das nicht auch sein, dass
das vielleicht total schlecht ist und da fühlte ich mich schon ziemlich ertappt
weil ich fürchte, auf mich trifft das ziemlich genau zu
Erwischt
es ist auch leider tatsächlich so, dass
ich das Gefühl habe, manchmal so, ja, aber das ist
halt auch, manchmal sind halt auch die Projekte, die man
macht, so vom Ergebnis her, da ist man
gar nicht so sehr am Ergebnis interessiert, weil
Aber das ist schlecht
doch. Das ist schlecht, ich weiß.
Das hat mir jetzt jemand letztens in einem
Jungle-Con-Talk erzählt. Wo ist dein purpose-driven-commitment?
Ja, das ist auch manchmal, aber das
ist auch wirklich schwierig, finde ich, bei manchen Projekten.
Also, naja,
aber das Programmieren selber macht ja Spaß
und da kann man sich auch drüber motivieren, aber stimmt,
dann hat man halt mit dem Ergebnis,
wenn es dann nicht so richtig passt, dann denkt man sich so,
naja Gott, also mir hat es schon Spaß gemacht.
Ja, genau.
Deshalb gibt es so viel schlechte Software.
Und das Schlimmste ist ja, selbst wenn es schlecht ist,
dann bedeutet das ja nur, dass wir noch mehr
programmieren müssen.
Was ich noch nicht verstanden habe, ist, warum wird die Software
denn schlechter, wenn man Spaß dabei hat?
Die wird nicht automatisch schlechter,
aber sie wird
auch nicht automatisch besser.
Und das ist so das Problem.
Was heißt denn besser? Da sind wir wieder vielleicht bei so einem
Quantifizierungsbeispiel, was das denn überhaupt ist.
Ja, das spielt keine Rolle.
Das spielt gar keine Rolle, wie du es quantifizierst,
weil das ist nicht das Ziel der Sache. Du orientierst dich nicht daran,
wie kann ich die Software besser machen,
sondern du orientierst dich erstmal
und unterbewusst daran,
wie kann ich mehr Software machen.
Und
das ist halt normalerweise nicht das Ziel,
mehr Software zu produzieren.
Beziehungsweise
da hat niemand was davon.
Da ist doch einer.
Ja, genau. Derjenige, der ist
hinterher nicht bezahlt.
Ja.
Okay. Ja, ich meine natürlich, also
besonders schlimm und das ist natürlich
auch so etwas, das wird ja auch immer gesagt
und ich erlebe das auch in Projekten so, dass es
halt besonders dann schwierig
ist, wenn man halt wenig Kontakt
zu den tatsächlichen Benutzern und
zum Endkunden hat. Und das kann natürlich auch
nochmal sein, dass das da so eine Rolle spielt, weil
wenn einem sozusagen der Endnutzer
tatsächlich mehr oder weniger häufiger
auf dem Schoß sitzt und sagt, was ihn quält,
dann kann man ja da vielleicht so eine
gewisse Empathietransferleistung erbringen und
sagen, na gut, okay, wenn der
so drunter leidet, dann kann ich da vielleicht auch mal was machen.
Das ist ja was anderes als ein quengelnder Manager, der wird dann
gerne mal... Ja, aber auch wenn man
den Kunden nie sieht. Aber ein quengelnder Manager hat jeder.
Ja, deswegen ja, also das ist nicht so effektiv.
Nee, überhaupt nicht.
Nee, das ist nicht so. Oder
Jira-Tickets, ja. Jira-Tickets machen jetzt nicht
unbedingt so empathische Reaktionen.
Ehrlich gesagt, ich
ja, also
das ist für mich aber auch
wie man die Tickets dann irgendwie schätzt, wie lange das dauert
das ist halt auch irgendwie so eine subjektive Sache und man kann halt
sich auch mal mehr Zeit lassen, mal weniger und so
mehr Zeit dann verbringen mit der
schönen ästhetischen Herangehensweise
diese Aufgabe zu
lösen, ne? Das ist für mich aber auch
so ein bisschen die Gegenhypothese, also auch
Software, die keinen Spaß macht zu schreiben, ist auch nicht gut
auch Kobol-Programme sind meistens nicht
super
und da möchte ich
niemandem vorwerfen, dass er Spaß dran hatte, die zu
schreiben. Kobalt, ist das nicht die 13. Kolonie in
Battlestar Galactica?
Ja, das ist...
Letztes Jahr hat man ja gesagt, das Schlimmste an Covid-19 ist,
dass es auch ein Jira-Ticket sein könnte.
Ja.
Wir mussten ein Projekt intern umbenennen,
weil irgendjemand das Delta genannt hatte.
Ja.
Aber ja, man fühlt sich auf jeden Fall ertappt, weil ich meine, jeder von uns hat schon mal Sachen so vor sich hingedudelt und die dann auf GitHub hochgeladen und irgendjemand anderes muss jetzt darunter leiden.
Also es ist auf jeden Fall schon so und das ist auch genau wie Daniel Poloschida da sagt, nicht gängig in anderen Berufsgruppen, dass die ihre Arbeit mit nach Hause nehmen.
Also das Beispiel, was er da bringt, ist, dass der Zahnarzt in seiner Freizeit normalerweise keine Zähne richtet, sondern das macht er halt nur beruhigt.
Ich stelle mir gerade so einen Zahnarzt vor, der eine Sammlung von Gebissen in seinem Garten legt.
Ja, und dann vielleicht auch mal ein bisschen drin rumbohrt und sagt, hier ist aber ein Wurzelkanal, den wir mal ganz dringend rausbohren müssen.
Ich glaube, zu so einem Zahnarzt würde ich nicht gehen wollen.
Ja, das Einzige, was mich tatsächlich nervt am Weiterprogrammieren ist, dass ich nur sitze und nicht stehen kann.
Schön ist ja die Idee, die ich mal gesehen habe.
Genau, beim Standing-Desk mit einer
Laufwand drunter, fand ich ja ziemlich cool.
Das wäre so eine Sache, das müsste ich eigentlich noch machen.
Dann kannst du noch die Geschwindigkeit, kannst du dann auch noch
irgendwie übertragen auf die Maus-Geschwindigkeit
oder sowas.
Weil ich mache das wirklich
auch sehr gerne, auch in der Freizeit, also wenn man irgendwie
Zeit hat, Sachen zu bauen, das ist halt irgendwie
so ein was Schaffendes, so was Schönes,
Kreationistisches, das ist echt was Tolles.
Das ist halt so ein bisschen wie mit Lego spielen.
Ja, aber niemand von uns würde
in ein Lego-Haus einziehen wollen.
Ja, ja, ja. Das ist ja irgendwie so ein Handwerk.
Man hat hinterher was Richtiges in der Hand. Also vielleicht sowas wie mit
Holz. Also nicht, dass ich jetzt irgendwo gut mit Holz arbeiten
konnte, aber so vom Gefühl her.
Das kann man schön machen, dann noch
lackieren und dann mit einem Schwung, einem Bogen
rein, ein ganz tolles Holz auswählen,
dann mit einer schönen Maserung und so.
Und dann eine ganz tolle Sache zusammenfliegen.
Das ist ja fast schon was Klischeehaftes.
Gerade zusammengesteckt.
Fast schon klischeehaft, dass Softwareentwickler
dann irgendwann zu Woodworkers werden.
Ja, das ist wahrscheinlich
auch tatsächlich halt sowas Ähnliches, nur
dass die Rahmenbedingungen halt nicht so schrecklich
sind, wenn man einen Schrein hat.
Ja, und dass es auch egal ist.
Es ist kein Manager, der hinter einem steht und sagt,
mach mal das hier, sondern es geht wirklich nur darum,
da was zu haben. Aber auch da,
da geht es ja auch tatsächlich mehr um das Ergebnis.
Da ist auch das Ergebnis sichtbarer. Du kannst hinterher
sagen, der Schrank ist gerade oder nicht.
Genau, wäre dann nicht ein
möglicher Ausweg, so ganz
naiv, wenn man
sein eigener Kunde wird,
wo man dann quasi,
Ja, dass man sagt, okay, ich bin halt dann derjenige,
der am Ergebnis auch interessiert ist,
weil es ist halt auch mein Produkt.
Genau, das würde ich halt auch sagen.
Ganz richtig, halt dieses Purpose-Driven,
dass du halt wichtig dafür brennst, dass du das machst,
so wie du dir das vorstellst, weil du halt diese User-Story
quasi selber in dir drin trägst, ja, zum Benutzen.
Aber den ich ja meistens gar nicht.
Ja, genau, aber wenn das halt so ist und halt irgendwie
ein Management das halt nicht hinkriegt, was verkackt,
dass du halt so eine Informationsasymmetrie bekommst
zwischen User-Story oder Management,
weißt, was richtig ist und du weißt, was du machen willst,
das wird halt schwierig zu managen.
Also das ist eigentlich unmöglich zu managen, weil du kannst, die meisten
Manager sind ja technisch jetzt nicht so affin,
kannst du irgendwas vom Pferd erzählen und das machen dann auch irgendwann
viele Leute, die halt keine Lust haben auf irgendwas.
Wir erzählen halt irgendwas von ganz, ganz
komplizierten Funktionen, die da geschrieben werden müssen
und so und dann dauert das halt
gefühlt ein bisschen länger,
bis nach zwei Teilen fertig und hast
wieder Zeit für die schönen Dinge oder so.
Du meinst, dann kannst du noch ein paar
Unit-Tests schreiben? Ja, zum Beispiel.
So nutzt man doch dann die Zeit, oder?
man schreibt Tests und Dokumentation
und... Ja, das fällt halt auch dann
meistens mal runter, weil die Leute immer sagen, ja, das ist alles
total unwichtig, oder so
Refactorings oder sowas.
Für einen selber als Programmierer ist es nicht ganz so
wichtig, ja.
Ja, für alle Leute,
die mitarbeiten, vielleicht.
Das war auf jeden Fall ein großer Paukenschlag,
so direkt zur Eröffnung der Konferenz
hat auch, ist super
gut angekommen und...
Programming for pleasure, Daniel Furchier.
Der macht auch sonst gute Talks.
Der hat auch schon welche über Dokumentationen gemacht,
die ich auch sehr gut fand.
Sind die eigentlich schon online, die Talks?
Ich glaube nicht.
Die müssen aber jetzt in den nächsten Tagen
irgendwann auf YouTube erscheinen, oder?
Ich glaube, 30 Tage habe ich irgendwo gehört,
aber ich weiß es nicht.
Wann war die nochmal genau?
Am 2. Juni.
2. Juni.
2. bis 6. Juni.
Dann ist ja jetzt in 10 Tagen alles da.
Müsste demnächst soweit sein.
Also ich weiß nicht, wie sie es machen, aber ja.
Cool.
Was hat euch denn noch super gut gefallen?
Also ich meine, das habt ihr vielleicht noch gar nicht gesagt.
die beiden hatten auch einen Talk, beziehungsweise einen Worktop,
die ich natürlich beide dann doch getalkt habe.
Der nächste Talk, der mir sehr gut gefallen hat, war der von
Jochen Wersdorfer, war sehr, fand ich sehr, sehr gut.
Jochen, erzähl,
hast du den auch geguckt? Erzähl doch mal.
Ich habe gerade übrigens das erste Mal deinen vollen Namen gesagt in diesem Podcast.
Oh je.
Ich glaube, auf der Webseite war der auch schon irgendwie drauf.
Hab ich dich gedoxed.
Kann man auch nicht wirklich verändern.
Ja,
nö, das, genau, also ich habe
den auch ein paar Mal, ich habe den, ich habe ja tatsächlich
so ein bisschen dann geübt und so
und dachte, oh, vielleicht kann ich
dann auch live halten. Das hat dann irgendwie nicht geklappt,
weil mein Video,
mein vielleicht ein wenig zu
elaboriertes Video-Setup das nicht zugelassen hat,
weil wenn man das als Webcam bei
Zoom registriert, dann wird die
Schrift so unscharf, dass man es nicht mehr lesen kann.
Um mal kurz euch vorzustellen, wie Jochen das macht.
Jochen schmeißt tatsächlich ein mega krasses
Technik-Setup, wie er schon mal gesagt hat. Oh, Content interessiert
gar nicht so, Technik ist das, was wichtig ist.
Schmeißt er dann alles halt
irgendwie in OBS rein mit einer ziemlich krassen Webcam
und ziemlich cool im Setup da auch
mit seinem großen, was ist das
für ein Fernsehstudio
Kontrollpult. Genau, das war so
ein Atem Mini von Blackmagic.
Und tatsächlich braucht man dann keinen OBS mehr. Das Ding
streamt selber. Ah ja, okay. Also siehst du noch nicht mal
OBS, du hast da einfach selbst konfiguriert
und dann, ja, das sah auch schon ziemlich cool aus,
muss ich sagen. Aber
wir wollten das gar nicht annehmen, hast du gerade
gesagt. Ja, zurück zum Content. Genau, das hat halt
dann nicht funktioniert live. Sonst hätte ich das auch
live gemacht. Ach, wegen Zoom? Genau.
Und da musste halt die Aufnahme verwendet werden,
die überraschend früh eingereicht werden musste.
Das hatte mich auch so ein bisschen Schweiß gekostet.
Oh ja.
Und ja, weil ich hatte doch gar keine Slides fertig und so.
Ja, die Story habe ich ja noch im Ohr.
Aber jetzt haben wir schon darüber gesprochen,
was oder wie du getalkt hast, aber über was denn?
Das ist ein Thema, mit dem ich seit einiger Zeit
irgendwie so ein bisschen hadere oder wo ich dann rumfeile.
Und zwar, was ich irgendwie ein bisschen doof finde, ist, wenn man so mit Files zu tun hat, also tatsächlich Dateien, irgendwie größere vor allen Dingen, also Bilder können auch schon größer werden oder Videos oder Audiodateien.
Und Audiodateien hat man natürlich irgendwie beim Podcasten schon zu tun und irgendwie die Seite für diesen Podcast hier, den habe ich ja auch mal irgendwann gebaut.
Und da ist es so, da verwende ich so ein CDN, um die Audio-Files auszuliefern.
Und auch wenn ich das jetzt in irgendwelchen Kundenprojekten sehe oder so, wenn Leute mit Files umgehen,
dann hinterlässt das meistens so ein, das ist irgendwie noch nicht so richtig optimal Ding bei mir,
weil oft hat man dann so Anforderungen wie, das habe ich jetzt beim Podcast nicht,
aber so in quasi, ja, wo man so Auftragsarbeiten,
dann hat man halt oft Leute,
die irgendwie Authentifizierung und Autorisierung haben wollen
für die Dateien, weil das Sachen sind,
die nicht unbedingt öffentlich sind.
Und dann wird es schon schwierig.
Und das, was halt alle machen eigentlich,
oder die meisten jedenfalls, wo ich das bisher gesehen habe,
ist, dass sie einfach irgendwie als Dateinahme
den Hash des Files nehmen oder so
und das irgendwo auf einen öffentlichen Webserver
packen und dann sagen, naja,
also wird schon keiner finden. Wird schon keiner erraten,
was der Hedge ist. Ja, genau. Ja, das ist
wirklich so, das wird schon keiner erraten.
Nee, das ist richtig, aber das Problem ist, es kann halt
irgendwie aus anderen Kanälen halt auch rausliegen,
wie zum Beispiel irgendwelchen Logfiles oder
auf der Client-Seite, dass halt irgendjemand
die Links verschickt. Speichert oder
das verschickt oder so. Ganz genau.
Und dann hat man halt. Du kannst es auch nie wieder zurücknehmen.
Ja. Wenn du es einmal jemandem gezeigt hast,
der hat es für immer. Genau.
Und das ist halt so ein bisschen
vielleicht nicht unbedingt das fassen will. Und wenn man dann sagt so,
oh, das ist aber eigentlich vielleicht nicht so ganz so optimal,
dann kommt halt häufig so, ja,
ach, das wird schon,
das ist jetzt,
das lösen wir dann später mal, keine Ahnung,
da müssen wir uns mal Gedanken drüber machen.
Ja, aber das ist halt dann schon eine relativ
zentrale Geschichte, dass Authentifizierung irgendwie
funktioniert. Und später
sich drum kümmern ist halt bei solchen Sachen oft ziemlich
schwierig, wenn man dann halt schon irgendwie
Dinge hat, die darauf basieren, dass das so funktioniert,
wie es funktioniert. Und wenn es kaputt funktioniert,
dann ist diese, das ist halt sehr schwer hinterher ein System nochmal reinzubringen und dann hat man halt eigentlich ein unsicheres System und das ist natürlich eigentlich nicht so richtig, dass man es haben möchte und das hat mich schon immer so ein bisschen geärgert, also ich habe auch schon gesehen, dass Leute das richtig machen, aber das ist halt eher so die Ausnahme und die Art.
Was wäre denn richtig? Was gibt es denn für Alternativen?
Genau, also das, was man tun kann, wäre halt, wenn man jetzt quasi das komplett alles selber hosten möchte, vielleicht so ein Nginx davor zu nehmen, davor zu haben.
Man hat ja sowieso immer irgendeine Art Reverse-Proxy vom Applikationsserver bei Django und da kann man ja jetzt, also auch diesen Lösungsansatz, den habe ich ja von dir, Johannes.
Gibt es da was, was man mit NGINX machen kann?
Ja, ja.
Genau.
Dann geht der Request vom Browser aus,
geht halt direkt zum Applikationsserver.
Aber der Applikationsserver schickt halt nicht das File zurück,
sondern der schickt halt eine leere Response zurück,
in der nur ein Header gesetzt ist.
Also Xen-File oder X-Excel heißt der, glaube ich, bei NGINX.
Wo dann drin steht, ja, ja, das ist schon okay.
Und dann ersetzt der Nginx die leere File-Response durch die echte File-Response.
Und wo kriegt der die her?
Ja, der braucht dann halt Zugriff auf, wie auch immer, das Verzeichnis oder was auch immer.
Also aus einer Datei, oder?
Ja, genau.
Okay, aber das ist ja schon mal ziemlich cool, oder?
Dann kann ich ja sagen, hier, diese Datei darfst du nur ausliefern, wenn folgende Vorbedingungen gelten.
Also ich kann die Vorbedingungen in meinem App-Server prüfen und das Ausliefern macht dann aber Nginx.
Also das ist ja schon mal ziemlich cool.
Damit ist eigentlich ziemlich super. Also das funktioniert
tatsächlich. Das einzige Problem, wo ich
sagen würde, naja, das ist halt so ein bisschen hässlich
an der Lösung, ist, dass
naja, also man hat
jetzt plötzlich zwei Systeme, die Zugriff auf alle
Daten haben müssen. Also
zumindest auf alle Dateien haben müssen.
Und es muss halt auch so verbunden sein, dass
die das beide korrekt finden. Genau. Und
du kannst es halt nicht mehr gut testen.
Ob jetzt deine
Applikation alle
Sicherheitsanforderungen noch erfüllt, kannst du in
Django-Tests allein nicht mehr machen.
weil dein Applikationsserver
kann ja sagen, nee, da darf jemand nicht
drauf zugreifen, dein Test überprüft das und sagt so,
super, hier ist alles richtig.
Und dein Nginx kann aber die Datei trotzdem ausliefern,
weil der irgendwie falsch konfiguriert ist oder keine Ahnung,
weil da sonst irgendwie was schiefgegangen ist.
Und das heißt, du merkst
unter Umständen nicht, wenn dein System kaputt geht,
weil du den einen Teil nicht mehr so
wirklich mittesten kannst, weil es halt auch schwierig ist,
das komplette System dann halt immer beim Entwickeln
hochzufahren mit Nginx und dem ganzen
Kram. Also eigentlich müsstest du es ja dann
mittesten.
Man verschiebt quasi so ein bisschen was von dieser Testlast in den operativen Bereich.
Weil im Endeffekt musst du ja dann das operative System testen und überprüfen.
Und du müsstest ja eigentlich sogar einen negativen Test machen.
Du musst ja nachweisen, dass Nginx diese Datei unter keinen Umständen ausliefert, außer wenn.
Und das ist natürlich sehr, sehr schwierig.
Aber gibt es denn da Echtweltbeispiele?
Das passiert doch in der echten Welt nicht, oder?
dass irgendwas offen konfiguriert ist, wo
Daten rumliegen. Das passiert so gut wie
die, ja. Also auch
diese Leaks, die dann immer gibt.
Das passiert ja
nicht. Also ich meine, tatsächlich ist auch eine der häufigsten
Sachen, die man so sieht, dass dann irgendwo jemand
halt sich mal irgendwelche Sachen angeguckt hat
und dann, oh, was ist denn da? Hier sehe ich
meine Dateien. Hm, was ist denn? Da gibt es halt vielleicht noch mehr.
Oder dass irgendwelche Backup-Server
offen sind oder dass irgendwelche Log-Server
offen sind oder dass irgendwelche. Ja, ja.
Und dann sind halt plötzlich alle Daten
von allen Leuten irgendwie öffentlich und das ist halt furchtbar
eigentlich.
Genau, also so kann man das halt
machen, aber dafür muss man jetzt, also ich würde
sagen, das ist auf jeden Fall schon somit die beste Lösung,
die ich so gesehen habe,
wie man das richtig machen kann.
Man kann das auch noch
machen, also wenn man jetzt die eigene
Infrastruktur komplett unter Kontrolle hat, wenn man das nicht
hat. Es hört sich halt auch so ein bisschen an, als wäre es
ein bisschen komplexer, zu dem
NGINX zu erzählen, dass er die selben Sachen versteht
für Authentifizierung, Autorisierung, wie zum Beispiel
die Applikationshilfe mit dem Django dahinter
oder so.
Nee, das ist gar nicht das Problem.
Das muss er nicht. Der Request geht ja durch
einen Applikationsserver. Das heißt, der Applikationsserver
entscheidet. Der Nginx
sieht nur den Header und macht dann, oder
macht eben nicht. Das heißt, das Einzige, was man quasi macht,
muss die richtigen Header setzen und dann läuft es.
Vom Applikationsserver aus, ja genau.
Das ist auch sowas. Da gab es dann in der Reaktion
auf den Talk, glaube ich, im Slack
oder so, hat dann jemand gesagt, da gibt es doch in Nginx
auch ein Ding, wo man
der Nginx dann beim Applikationsserver nachfragt,
ob das authentifiziert ist oder nicht. Das ist auch sehr schön.
Das ist, also würde ich sagen,
funktioniert ähnlich gut und das ist vielleicht sogar noch mal
ein bisschen besser, weil man es dann
schlechter falsch konfigurieren kann, weil
ja.
Es ist leichter testbar, oder?
Es ist leichter testbar. Wenn die Authentifizierung
nicht da ist, darf der einfach nichts ausliefern.
Das kann man leichter nachweisen.
Also insofern, das kannte ich noch gar nicht und das
klingt eigentlich auch sehr gut.
Das ist durchaus eine Geschichte, die man machen kann.
Das Einzige, was daran so ein bisschen
blöd ist, ist halt, es funktioniert nur,
wenn man, also es macht die Infrastruktur
komplizierter und es funktioniert nur, wenn man die komplette Kontrolle
drüber hat. Wenn man jetzt ein CDN verwendet oder so,
geht das halt nicht mehr so richtig. Ja, was könnte
ich denn machen, wenn ich meine Dateien auf S3 habe?
Die kann ich ja auch auf Private schalten
oder Public. Gibt es denn da auch eine Möglichkeit?
Erzähl mal. Genau, ja. Also was man
da tun kann, ist, man benutzt
entweder Signed Cookies oder halt
signierte URLs
und
über den Applikationsserver aus. Also das
bedeutet im Grunde, die URL, die man an den Browser ausliefert,
da steht halt,
also ist halt eine Signatur drin. Ein Token
dran oder? Ja, so was. Also
es ist ein bisschen mehr Daten, es ist nicht nur
die Signatur, sondern es ist halt immer noch so
also ich weiß nicht, ob das dann letztendlich JSON ist
oder so, also das kann man auch, ist halt wahrscheinlich
gibt es verschiedene Techniken für, genau
da steht dann halt meistens noch sowas drin
wie, also diese URL ist
jetzt 30 Minuten gültig ab jetzt, oder ab
diesem Zeitstempel, oder die ist halt nur
gültig für IP-Adressen aus
dem Adressbereich oder sowas. Oder nur für einen Klick
oder sowas, oder für einen Aufruf oder sowas?
Ja, weiß ich nicht, ob man das da einstellen kann, also
IP-Adressen und Zeit weiß ich, dass es
bei Amazon geht, auf jeden Fall
und das kann man halt entweder in die URL packen
oder man kann es halt sozusagen vom
Server aus als Cookie setzen
und wenn das dann quasi,
wenn dieser Request, da kommt es halt
darauf an, wie die Domains aussehen und so
und wenn das eine andere Domain ist, ist es manchmal vielleicht schwierig
also ob man jetzt als
Applikationsserver ein Cookie setzen kann für
die Domain, unter der dann tatsächlich
die Files liegen, aber wenn man das kann, kann man das
halt auch einfach so als Cookie setzen
und
ja, das
funktioniert halt auch.
Das ist auch richtig
eigentlich sozusagen in Anführungsstrichen
ordentlich, aber man hat halt immer noch
das gleiche Problem, dass
eigentlich ist es ein bisschen schlechter als
die Lösung mit dem Nginx, weil man
halt nicht wirklich von dem
CDN aus überprüfen kann, ob die Autorisierung noch
da ist oder nicht. Also wenn man jetzt in Django Admin
sagt, diese Files, dieser User,
darf die nicht mehr sehen, dann
kann das halt nicht sofort funktionieren,
sondern wenn man halt eine gültige URL hat, dann
ja, funktioniert die erst mal
weiter, zumindest 30 Minuten lang oder so.
Gut, ist dann halt nicht mehr so schlimm, als wäre die für immer
gültig, aber
auch da reicht es ja unter Umständen schon,
um
irgendwie die Daten daraus zu kriegen.
Es ist halt so ein bisschen, also es ist
besser als nichts zu machen, aber es ist halt immer noch so ein bisschen
so, ah, so richtig schön ist es eigentlich nicht.
Ja.
Und genau.
Ja, also das sind halt so die beiden
Ansätze, wie man das ordentlich macht eigentlich.
Aber was ist denn jetzt die richtige Lösung?
Was kann man denn heutzutage noch besser machen?
Genau, meine Idee an der Stelle war,
okay, naja, es muss im Grunde über den Applikationsserver gehen,
weil der der Einzige ist, der weiß,
ob jetzt ein User irgendwas sehen darf oder nicht.
Das kann man auch nicht irgendwie großartig anders machen,
ohne Probleme zu bekommen.
Wie wäre es denn, wenn der einfach selber die Files ausliefert?
Aber davon wird ja erstmal abgeraten, oder?
hast du Worker beschäftigt und dann hast du
nur so und so viele App-Server
und dann sind die
langsam und brauchen viel Speicher und so.
Genau, also in allen Tutorials
steht immer drin, nee, macht das nicht. Also wenn ihr
irgendwie Files ausliefern wollt, macht das über einen
getrennten App-Server, der da statt
Files direkt ausliefern kann oder macht das mit White Noise
und CDN oder so, aber
macht das nicht über den Applikations-Server, weil das Problem
beim Applikations-Server ist halt, dass es normalerweise
standardmäßig
ein Pre-Fogged, also sozusagen
Es gibt mehrere Prozesse, die halt Requests beantworten, davon gibt es halt so ein paar, eine Handvoll vielleicht oder allgemein vielleicht zweimal Anzahl der Cores plus eins oder so, was halt halbwegs optimal ist und solange die irgendwas ausliefern, sind die halt belegt und wenn ich jetzt einen Pfeil ausliefer, das groß ist oder einen kleinen Tab, der sehr wenig Bandbreite hat, dann kann das halt lange dauern und solange wie das dauert, ist der Worker-Prozess sozusagen belegt
und wenn alle Worker-Prozesse belegt
sind, dann kann niemand mehr anrufen
und dann ist es schlecht.
das hinausläuft.
Und genau.
Ja, daher sollte man das nicht machen,
und das kann schnell passieren. Wenn man eine Webseite hat,
da sind ja viele Bilder drauf.
Auch die Browser, die fragen ja inzwischen
Concurrent ab und so.
Dann ist es halt relativ schnell vorbei mit den Workern.
Und
ja, dann müssen halt
andere Clients warten.
Und das ist natürlich schlecht, weil das hat halt
direkten Einfluss auf die User Experience,
weil entweder dauert es länger oder noch schlimmer.
Es gibt halt eine Fehlermeldung, weil irgendwas timeoutet.
Das heißt, man müsste die auch konkurrent bedienen.
Genau, und das kann dieses Pre-Forked-Worker-Modell-Synchronen-Sachen-Ausliefern eigentlich nicht leisten.
Deswegen wird immer davon abgeraten.
Aber wir haben ja jetzt Async-Await in Python seit einiger Zeit.
In Django noch nicht so lange, weil da konnte es halt lange nicht so richtig verwendet werden,
weil die Standardschnittstelle zwischen Applikationsserver und Web-Framework ist halt WSGI.
Und WSGI kann das halt einfach nicht.
Da ist halt, das sind halt
synchrone Funktionsaufrufe, da kannst du auch nichts machen.
Und
ASGI, also der quasi
Nachfolger, der halt dann auch
sozusagen asynchrone
Dinge
kann, der ist halt noch nicht so alt,
ist auch quasi auch im Kontext von
im
Django-Kontext irgendwie entstanden.
Der Standard ist von Andrew Godwin geschrieben worden,
der halt auch... Ja, das habe ich im Janals-Projekt
aus dem Janals-Projekt, das ist rausgefallen.
Genau und damit geht das dann, aber Unterstützung für die Syntax war auch lange nicht möglich, weil Django lange Zeit noch Python 2 zum Beispiel unterstützt hat bis Dezember 2019, also bis Django 3 rausgekommen ist und mit Python 2 geht es gar nicht, weil da gibt es einfach nicht die Syntax für, so Async Await Syntax geht damit nicht und auch mit Python 3.5 ging das nicht gut.
ich weiß ehrlich gesagt nicht genau, woran das
liegt, also weil die Syntax kam eigentlich mit
3.5, aber alle Bibliotheken, die das
irgendwie, die Async Await unterstützen, die sagen
alle immer, ja, erst ab Python 3.6, da ist wohl
irgendwas Wichtiges noch passiert, aber ich habe nie so richtig
rausgefunden, was. Vielleicht sind es auch
einfach nur die F-Springs und alle sagen so,
ach, wenn wir jetzt schon was Modernes haben, wollen wir auch F-Springs
haben und dann geht das halt erst
ab 3.6, ich habe keine Ahnung.
Und ja.
Aber ich meine, 3.5 und 3.6 macht jetzt für uns
nicht so den Riesenunterschied, oder? Wir sind ja alle modern.
Auch Debian ist inzwischen auf 3.8
und oh wow, okay.
Ja, genau.
Jedenfalls also
die Syntax kann man, also dass es überhaupt geht
ist halt ab
Django 3.0 so.
Support für Python 2
und für Python 3.5 gedroppt
und seitdem gibt es auch
Unterstützung für ASGI und halt auch
prinzipiell die Möglichkeit
AsyncIO-Syntax zu verwenden in Django.
Aber es gab noch keine AsyncViews.
Das heißt, man konnte keine
AsyncFileResponse schreiben,
weil, naja,
Isingviews gab es halt einfach nicht. Und das kam
erst dazu im August
letzten Jahres, August 2020.
Das heißt, es geht noch gar nicht so lange.
August 2019 meinst du?
Nee, 2020.
Letztes Jahr war doch 2019.
Ach ja, okay.
Ach ja.
Ja, okay,
auf jeden Fall gibt es das erst seit ungefähr einem Jahr.
Genau. Und damals hatte ich ja auch
schon ein bisschen... Warum ist das cool?
Genau, das ist halt total cool, weil
das bedeutet eigentlich,
dass man jetzt so richtig Async-Sachen mit Django
tun kann. Was man auch nicht tun
kann, was auch total cool wäre, aber das wird halt noch ein bisschen
dauern, ist halt tatsächlich
Async, die Datenbank
fragen oder so, aber man hat zumindest
schon mal Async-Views. Und das ist halt
hilfreich.
Ich hatte damals einen Artikel
auch drüber geschrieben, mit Dominik zusammen.
Genau, der ist sogar
in der Zeitung erschienen, auf Deutsch dann, unter deinem Blog.
Echt? Cool.
Darf man das sagen, Entwickler?
oder? Ja, ich glaube, ja.
Schickle-Magazin war das.
Und
genau, da haben wir überlegt, okay, was für
Anwendungsfälle gibt es denn jetzt eigentlich, wenn man schon
Async-Kram machen kann?
Und der
Anwendungsfall, den wir dann da benutzt haben, war,
du machst halt
in der Django-Applikation halt vielleicht ganz viele
API-Zugriffe irgendwo nach außen hin und
möchtest halt nicht, dass sich die
Latenzen, die du dann beim Abfragen dieser
Requests hast, halt aufsummieren, sondern
dass halt der
die Latenz nur so lang ist, wie der längste
Request, den du machst. Und dann schickst du einfach all die
Requests, die du zu irgendwelchen APIs machst, halt gleichzeitig
los und
die Antworten kommen halt sozusagen dann
auch concurrent zurück und
nur, also die Latenz wird
bestimmt durch die langsamste API,
aber nicht mehr durch die Summe aller
Requests. Und das
macht es dann halt schon deutlich schneller. Also wenn du da viele
APIs fragst, dann kann es sein, dass du da halt
in Größenordnung schneller
bist oder so. Und das ist
dann ja schon praktisch.
Und das war so der Anwendungsfall.
Hatten wir da nicht auch drüber gesprochen in der
Async-Episode? Ja, ja, bestimmt.
Ja, genau, da hatten wir ja auch schon mal
zwei Episoden dazu gemacht.
Wir brauchen noch mehr.
Thema, da kann man immer noch mal drüber sprechen.
Ja, vielleicht sogar alle gleichzeitig.
Wenn man ein Thema einmal drin hat, dann muss man das auch ein bisschen ausschalten.
Ja, genau.
Aber jetzt, genau, ist mir dann halt irgendwann,
das war so Anfang des Jahres, dann dachte ich so,
ach, wenn man jetzt schon so Async-Evade hat,
vielleicht ist ja tatsächlich Files-Serven
ein guter Anwendungsfall,
weil es ist ja immer so ein bisschen hässlich,
so richtig toll ist es nie und
eigentlich könnte man ja jetzt eine Async
File Response schreiben, die
die Daten sozusagen da
so asynchron rausstreamt, ohne
zu blockieren und dann
müsste das ja eigentlich, müsste ich ja quasi beliebig
viele Clients
den Files ausliefern können.
Und dann habe ich
dann halt so ein bisschen rumprobiert und
hat so ein bisschen gedauert und irgendwann aber
dachte ich so, okay, das funktioniert tatsächlich und
ja, dann habe ich daraus halt
dann hat
der Johannes erzählt, dass er dann irgendwas
bei der Django.eu eingereicht hat
und da dachte ich so, das muss ich dann auch machen
den Talk eingereicht haben
der soziale Druck
ja und
genau, das war dann auch Thema
des Talks im Grunde und ja, es
funktioniert auch tatsächlich, ich habe jetzt
ich habe unterwegs auch
Methoden gefunden, wie man das gleiche hinkriegt
und auch schon vorher hinkriegen
konnte, ohne sich so zu verrenken.
Insofern war es
vielleicht alles nicht so richtig notwendig.
Ja, aber das ist ja schon sauberer,
was du da geschrieben hast. Wir haben ja die Tests
gesehen und in einigen
Tagen kann vielleicht jeder auch sich diesen Talk
selber angucken. Ja, ich packe das.
Ist ja schon deutlich sauberer und deutlich einfacher.
Wirst du das auch an
Django schicken?
Ich mache dann einfach ein
Party-Package draus.
Das wäre ja prinzipiell was, was vielleicht
auch für Django an sich interessant ist.
Ja, das Problem ist,
leider funktioniert es nicht so
richtig, kann man es nicht einfach in Django,
könnte man es nicht in Django reinbauen
oder könnte man schon, aber dazu müsste man
den ASGI-Händler, das ist so
das Ding, was halt mit
die Applikation ist, quasi die
ASGI-Applikation, das ist halt der ASGI-Händler
in Django.
Ach, den hast du einfach mal gemunkeypatcht, oder?
Naja, den müsste man anpassen
und das ist natürlich nicht so schön.
Ja gut, aber das ist in MPR auch prinzipiell möglich.
Oder dass man Subklassen anbietet oder sowas.
Ja, muss man
mal mit jemandem
drüber sprechen. Ja genau, dann machst du halt den
ASCII mit Async-File-Response-Händler.
Genau, aber den habe ich
jetzt einfach erstmal in einem anderen Paket drin und wenn man
das verwenden möchte, dann muss man das halt
entweder get
Async-File-Response-Händler
oder Application
importieren oder halt den Händler direkt
und dann die Applikation selber instanziieren
und dann geht das, aber das ist halt schon
ein Umbau an Django. Das Problem ist, ich weiß halt nicht, was das alles
kaputt machen würde.
Da kann es schon sein, dass einige Dinge nicht mehr funktionieren.
Ja, genau, dafür gibt es Tests.
Ja.
Ja, klingt auf jeden Fall ziemlich cool. Das heißt, man kann jetzt
einfach mit dem Dango-Applikations-Server
seine Files direkt ausliefern.
Man muss sie nicht mehr irgendwie außen vom
Web-Server quasi routen lassen, sondern man kann direkt sagen,
Dango, hey, nimm die doch mal direkt aus.
Was nutzt man dafür? Dango-Storages raus oder so
und liefer die mal mit.
Ja, und das, achso,
das war damals, als ich den, damals,
vor zwei Wochen,
war das
noch nicht so klar. Also man kann auch irgendwie
ein selbst gehostetes S3
oder so benutzen, weil das ist ja eigentlich
auch mein Ziel. Ich habe es mit dem Filesystem gezeigt,
aber Filesystem ist ja eigentlich so ein bisschen langweilig, weil
Wie hostet man S3 selber? Minio?
Minio, genau.
Weil man möchte eigentlich nicht,
dass User
selbst so Content,
Files, wo sie den Content kontrollieren, in das gleiche
Filesystem nehmen kann, in dem die Applikation
läuft. Das ist halt auch so ein bisschen gefährlich.
Und man hat dann das Synchronisationsproblem,
kann man natürlich irgendwie so ein
Samba-Share nehmen oder NFS oder was weiß ich.
Oder 7.
Geht alles, aber ist halt auch so ein bisschen
äh.
Ancient Relaying.
Ja, also die
Standard
Geschichte, wie man das selber hostet
momentan, also so ein Object Store wie
S3 oder so,
ist halt wohl momentan Minio.
Da müssen wir ja quasi direkt so einen kleinen Exkurs
machen, weil an der Stelle, das hast du alles
gezeigt auf deinem neuen
Twitch-Stream.
Genau, genau, genau.
Die Entwicklung daran, die habe ich jetzt gerade mal gestreamt, weil ich dachte so,
jetzt konnte ich dieses Atem-Mini-Dings
da gar nicht auf den Talk einsetzen.
Da muss ich es auf irgendwas anderes benutzen.
Also Jochen hat tatsächlich in der letzten Woche
oder in den letzten zwei Wochen ein bisschen mehr auf Twitch gestreamt
und auf YouTube gleichzeitig und da seine Sachen
hochgeladen. Da könnt ihr ihm ein bisschen beim Live-Programmieren
mal gucken. Das ist vielleicht ein bisschen was anderes, als nur so
zu theorisieren.
Sondern halt auch mal tatsächlich live zu sehen,
wie Jochen das denn so macht.
Ich da vorsitze und keine Ahnung habe, was ich da eigentlich tue.
Genau, Jochen ist auch nur Mensch und macht die ganze Zeit Fehler und so und mir fällt
wenn ich da vorsitze, ich möchte die ganze Zeit
hier so einen Stock nehmen und
Bist du auch wünschend gegen Jochen? Kann man sich wünschen, was du
programmierst? Oder programmierst du nur, was
dir Freude macht?
Ja,
prinzipiell kein Problem, ja klar.
Vielleicht gegen eine
kleine Spende, kannst du vielleicht
Requests annehmen.
Ja, genau.
Mir sind auch immer wieder aufgefallen, schöne Sachen da
bei dir, die du schön gemacht hast.
Ich packe den Link mal rein, mal gucken, ob
da... Immer wenn ich denke, hä, das
hätte ich doch ganz anders gemacht, fällt Jochen dann eine halbe Stunde
später auf, oh, das kann man ja auch anders machen.
Ja, aber ich meine, so ist das halt.
Mir sind da auch schon tatsächlich live Dinge passiert,
wie, ich habe
da live einen Bug in irgendeiner
Library gefunden, sozusagen, und
dann sitzt da, also ich hatte bisher
immer so den Impuls dann zu sagen, so, okay,
das muss ich dann mal irgendwann debuggen, wenn ich Zeit habe, weil
das ist zu langweilig.
Immer wieder, aber
das ging, glaube ich. Also ich meine, aber es ist ja vielleicht
auch ganz gut mal zu sehen, was man da so
rumsucht. Also Jochen benutzt dafür
übrigens NBDEV.
Da hatten wir auch schon mal eine Folge ein bisschen eingeleitet.
Genau, das mache ich eigentlich nur, weil
ich das Projekt ganz cool fand.
Das mache ich jetzt nicht unbedingt mit allen Sachen so, aber für das
Ding dachte ich, kann ich das machen.
Du musst das ja nicht nochmal anders machen, also nochmal
in VI und einmal in VS Code
oder so, da können wir mal schauen. Vielleicht sogar in PyCharm,
dass man so ein bisschen einmal zeigt, wie das denn überall so geht.
Genau, das habe ich
auf jeden Fall auch vor.
Ja, genau.
Vielleicht kriegen wir das ja auch mit dem Podcast nochmal
da so ein bisschen
den vielleicht so ein bisschen
Video-Live-
Live-Schalter gestalten.
Mal gucken, ob wir dafür Zuschauer
begeistern können.
Ja, cool. Genau.
Ich glaube, noch jemand hat halt tatsächlich
einen Workshop bei der dann begonnen.
Ja, ich bin ja
quasi schuld dran, dass der ja von dem
Talk überhaupt eingereicht hat, weil ich
hab das nämlich auch gemacht und das war bei mir auch so ein bisschen
so halb spontan.
Also lange geplant.
Nee, eigentlich überhaupt nicht, weil die Botschaft auf der Webseite, die die Organisierer, die übrigens großartig sind, so verbreiten, ist ja, ja, selbst wenn du dir nicht sicher bist, probier es halt mal. Komm, reich was ein, im schlimmsten Fall machst du keinen Talk. Im schlimmsten Fall musst du einen Talk machen.
Und so war es dann auch so ein bisschen. Ich habe mir überlegt, was andere Menschen interessieren könnte und was ich Interessantes sagen könnte und habe es einfach mal so ein kleines bisschen reingeschrieben. Die Talk-Beschreibung hat sich dann auch im Laufe der Zeit noch mehrmals geändert. Es ist auch nicht genau das gewesen, was ich mir anfänglich gedacht hatte. Aber ja, ich habe einen Talk eingereicht, der dann als Workshop akzeptiert wurde. Und es ging so ein bisschen darum, wie ich Django-Projekte mache.
Also so ein bisschen das, was du auch von dir in unseren Podcast-Folgen erzählt hast wahrscheinlich.
Genau, so ein bisschen Best Practices oder Programmierer-Erfahrung.
Ich programmiere jetzt schon sehr lange in Django.
Ich habe mal nachgeguckt, welches die erste Version war, die ich benutzt habe.
Das war die 0.96.
Ist schon eine ganze Weile her, das war 2005.
Also ich habe jetzt tatsächlich 15 Jahre Django-Erfahrung.
15? Das ist ja noch 2020.
Ja, wieso?
Ich habe den Witz eben nicht verstanden, deswegen habe ich ihn noch nicht gefasst.
Wir müssen den Witz jetzt einfach so lange wiederholen, bis jeder glaubt.
Ich habe also über 15 Jahre Django-Erfahrung und da sammeln sich einfach so Dinge an, die man sich angewöhnt, an die man tut und die dann auch sinnvoll sind.
Und Best Practices dazu zu sagen, ist ein bisschen zu hoch geflogen, weil Best Practices heißt ja, dass das jeder so macht oder jeder so machen sollte.
Und so weit will ich gar nicht gehen.
Ich will eigentlich nur sagen, hier folgende Dinge
haben sich für mich bewährt und
hier ist auch die Begründung.
Und ja, das habe ich dann so ein bisschen da reingepackt.
Also ich hatte vier Bereiche
mehr aufgeschrieben.
Während des Live-Talks
sind es leider nur drei Bereiche geworden, aber
es gibt ja genau wie beim
Jochen auch eine sehr frühzeitig eingereichte
Aufnahme,
die auch auf meiner Webseite
zur Verfügung steht. Können wir nachher gerne verlinken.
Wagen euch auch ein bisschen mehr für Einsteiger
geeignet, glaube ich, den Talk, den du gemacht hast, das was doch
jetzt. Ja, es war so ein bisschen
gedacht, dass ich vier verschiedene Bereiche habe
und manche sind für Einsteiger gut und manche
sind eher für Fortgeschrittenere
gut.
Was dann halt am Ende so ein kleines
bisschen rausgefallen ist. Diese Einsteiger
Sachen, wobei auch erfahrene
Leute, also ich
wechsle da immer so hin und her. Der Bereich,
der mich da hauptsächlich beschäftigt
war, ist Projektstruktur.
Wo kommt Code hin? Wie heißen die Dateien?
Wie sorge ich dafür, dass ich
die Sachen alle wiederfinde?
Wie sorge ich dafür, dass ich auch in einem großen Projekt
den Überblick bewahre? Und sowas
halt. Und ich wechsle da immer
so hin und her. Es gibt ja Leute, die sind da ganz krass drauf.
Die haben dann ihre extrem
angepassten Cookie-Cutter-Vorlagen,
wo alles anders ist, wo alles
Custom ist.
Und es gibt Leute, die benutzen Django
Start Project. Und ich
wechsle da immer so ein bisschen hin und her.
Ich sehe die Vorteile von beidem. Und in
den letzten Jahren bin ich mehr so in Richtung
Django Start Project gegangen.
Weil das schon eine gute Basis
ist und weil das jeder machen kann
und weil das
jeder auch versteht. Aber das hat so
ein paar Dinge, die mir da nicht so gut gefallen.
Zum Beispiel das Apps-Folder.
Zum Beispiel der Apps-Folder, ja. Ich finde,
alle Apps, die man selbst in seinem Code
hat, die gehören in ein eigenes Verzeichnis. Die gehören
nicht in das Projektverzeichnis rein.
Bei dem Projektverzeichnis sind ganz viele andere Sachen drin.
Config zum Beispiel. Und dass das Config-Verzeichnis
nicht Config heißt, ist auch sowas.
Passe ich in jedem
meiner Projekte an, ja. Und
das einfach mal sozusagen zusammenzuholen
und zusammenzufassen und ein bisschen drüber zu sprechen
auch, was
da für Schritte drin sind.
War super hilfreich. Inzwischen habe ich das
Ganze auch in ein Template verpasst. Django
hat tatsächlich einen Template-Mechanismus
für Startproject und für Startapp.
Den kannte ich auch noch nicht. Das
fand ich auch sehr interessant. Das wusste ich nicht.
Vollnützliche Informationen, ja. Echt sehr gut.
Ich habe da jetzt auch inzwischen
das so eben zusammengefasst,
dass man also mit Startproject
slash slash Template
geht tatsächlich sogar von GitHub direkt,
dass man
da meine Konventionen
reinnehmen kann, die fast genauso sind wie die
von Django und
eben da mehr Struktur reinbringen.
Oh, das finde ich auch nochmal interessant, wie man
das nochmal aufsetzt und das editiert, dass man sein
eigenes Skeleton-Start-Template
über das Django-Start-Project-Kommando
reinbekommt. Das fände ich auch nochmal spannend.
Ja, können wir gerne mal
besprechen oder vielleicht machen wir da einfach eine Bibliothek
dafür, Dominik. Wollte ich sowieso noch
machen. Können wir mal zusammenprogrammieren.
Genau, also es war einfach so ein bisschen, wie
entwickle ich und was hat sich für mich bewährt
und
dann eben, genau,
so ein bisschen im Dialog, so ein bisschen
drüber sprechen, was bei den anderen
so ist. Und das hat super gut funktioniert. Das ist auch, glaube ich,
ganz gut angekommen.
Klingt spannend.
Müsst ihr euch auf jeden Fall mal angucken.
Kommt auch in zehn Tagen.
Genau, wir verlinken das.
Oder eben meine Aufnahme ist schon auf der Seite.
Das war so
die sechste oder siebte Aufnahme, die ich gemacht habe.
Also die ist ganz okay.
Ja, das fand ich auch, ehrlich gesagt, damit hätte ich nicht gerechnet,
wie oft man dann ein paar Mal aufgenommen
und dann passiert irgendein Scheiß.
Das war einfach nochmal.
Fällt einem die Kaffeetasse aus der Hand.
Bei der letzten Aufnahme, die ich
nehmen wollte, das war dann auch schon am Tag der
Abgabe, habe ich
drei verschiedene Aufnahmen gemacht.
Audio-Aufnahme und Kamera-Aufnahme und
Screencast. Und da wollte ich
zusammenschneiden und dann war der Screencast kaputt.
Und dann habe ich gedacht, jetzt muss ich nochmal
eine Stunde mich hinsetzen und nochmal das
ganze Ding machen. Aber zum Glück war es nur die
Datei auf der SSD, die
auf der mobilen SSD, die ich fertig kopiert hatte.
Konnte ich dann tatsächlich noch retten.
Und da war ich so,
ich hätte sonst,
der Rest des Tages wäre sonst futsch gewesen.
Ja, also dein Probevideo ist auch abgestürzt, glaube ich,
30 Sekunden vor Ende. Das heißt, man hat deine Grußworte
nicht mehr ganz mitbekommen. Das hast du ja dann auch noch gefixt.
Habe ich auch noch gefixt, genau. Also es
gab da verschiedene Aufnahmen, die alle nicht so gut
waren und dann gab es alle, die ganz okay waren.
Also ihr merkt, es ist auch eine relativ viel technische Detailarbeit
hinten. Ja, aber tatsächlich
erstaunlich viel mehr Vorbereitung,
als ich gedacht hätte.
Genau. Und aber
was ich sagen muss, also das war
dann, da war Johannes' Vortrag auch echt
einer der
positiv herausstechendsten,
also sowohl Video- als auch Audioqualität war gut.
Während
das aber, das war...
Ja, ja.
Tatsächlich muss man leider sagen, also ich fand,
oft war das nicht so gut. Ich hab dann
ich hatte während der Konferenz gar nicht so richtig
Zeit, das live zu verfolgen, weil
Dinge
passieren, genau.
Aber ich habe die dann alle versucht
nachzuhören hinterher und habe die dann
halt auf dem Telefon
laufen lassen,
weil, ja, auch hier komme ich nicht von Rechner
setzen. Dinge passieren, man hat keine Zeit.
Und das ging
auch ganz gut, aber was
mich halt dann schon so nach dem dritten, vierten
Talk, den ich gehört habe, angenervt hat, ist halt,
dass die Audioqualität oft nicht gut
ist, weil was viele Leute dann
machen ist, sie stellen sich halt
nehmen halt ihr Laptop oder sonst irgendwas und stellen sich dann
halt irgendwie ein paar Meter dahinter, damit sie halt irgendwie
zu sehen sind und dann sind sie halt weit
vom Mikrofon weg und das Mikrofon ist schon schlecht
und dann wird das nochmal
kaputt komprimiert von irgendwie Zoom
oder so und dann gehen die Lüfter an und
dann ist es schwer zu
verstehen. Also ich hatte tatsächlich bei einigen
Talks das Problem, dass ich kaum verstanden
habe und ich habe die Lautstärke auf dem Telefon
komplett aufgedreht und trotzdem Schwierigkeiten
gehabt, das richtig zu verstehen und es ist
vor allen Dingen auch anstrengend,
selbst wenn man es verstehen kann,
Audio zu hören, wo man immer so,
dass es halt so schlecht ist, dass man sich
wirklich anstrengen muss, um es hören zu können.
Und da denke ich vielleicht
auch manchmal, vielleicht sollte man,
da gab es ja auch so einen Talk, den gab es
diesmal nicht, aber glaube ich bei der letzten
DjangoCon EU,
How to get on the stage.
Der war verlinkt,
der war verlinkt für die Sprecher, damit die wissen,
was auf sie zukommt.
Und vielleicht kann man irgendwie so, wie kriegt man
eigentlich zumindest verständliches Audio
und nicht so, beim Video ist
ja fast egal, das ist gar nicht so furchtbar
wichtig, aber ich finde das Audio ist halt schon
so das halt, was man verstehen können
sollte, wenn man den Inhalt mitbekommen möchte
und wie kriegt man das so hin, dass man das
verstehen kann und dass das nicht total schrecklich ist
und ja, weil das war
durchgängig, fand ich bei
vielen nicht gut. Es gab
ein paar Ausnahmen, eben Johannes eine
löbliche Ausnahme, aber
bei vielen war das nicht so richtig toll.
Man tut, was man kann.
Ja, das ist schade, dass es dann oft an so technischen Sachen auch hängt, aber das ist halt wirklich bei so einer Remote-Konferenz eine sehr inhomogene Mischung von Technik und Menschen und Ideen und Anforderungen und Zeit auch.
Nicht mir ist doch völlig klar, dass ich hier damit beschäftigen möchte.
Was man eigentlich bräuchte, wäre irgendwie so Sets, die man verschickt, wo eine gute Kamera dabei ist und ein gutes Mikrofon und die dann hinterher wieder zurückgeschickt werden.
und irgendwie ein Tutorial, wie man das anschließt
und wie man das, weil es ist halt dummerweise,
es ist leider schwieriger, als man so denkt
und genau. Ja, eigentlich macht man alles mit
so bunten Kabeln, die immer genau an die richtigen Stecker passen,
also die Stecker sehen genau so aus, wie die klingen
und dann steckt man es ein und dann hat man auf einen Knopf und dann läuft es.
Ja, USB, einfach nur
einen USB-Anschluss.
Ja, was mich tatsächlich so ein bisschen,
was mir so ein bisschen
negativ aufgefallen ist, war, dass
diese Zoom-Meetings oft qualitativ
nicht so cool waren, ja.
Also ich habe jetzt auch nicht die beste Kamera,
aufgestellt gehabt, aber ich sah halt auf dem Bild
echt krümelig aus auch.
Und danach, nach den
Talks, waren immer noch Jitsi,
hatten sie immer noch einen Jitsi-Raum für den jeweiligen
Talk, auch super, ja, großartige Idee,
dass man sozusagen noch so dieses Gefühl
hat, ich gehe jetzt vor zu dem Sprecher so, ich gehe
zur Bühne und spreche noch fünf Minuten mit dem.
Haben sie super hingekriegt
und da war die Bildqualität bei den Sprechern dann
oft wesentlich besser als vorher in diesem Zoom-Meeting.
Das ist
natürlich schon irgendwie schade.
Das ist schon irgendwie schade.
Aber von der ganzen Technikkritik
jetzt hier und den Bildern.
Was hat euch denn inhaltlich noch super gefallen?
Aber das ist halt das Einzige, was man kritisieren
kann. Das alles andere war halt super.
Die Vorträge waren super und
die Community war super.
Die hatten ein Tool, das heißt
Gather Town.
Oh ja, Gather Town ist großartig.
Da kann man nicht rumlaufen mit einem kleinen Avatar
und sich dann quasi live auf dem Konferenzgelände
treffen mit so einem Pixel-Avatar.
Und da kann man sich auch dann sehen, weil dann nämlich, wenn man sich da live
begegnet, dann geht nämlich die Kamera an und man kann
den Ton hören und dann kann man sich irgendwie auf dem Dorfplatz
versammeln oder ich weiß jetzt nicht genau, ich war gar nicht ja bei der
Dango Condor Live im Gather Town.
Es hat einfach eine Räumlichkeit,
du bist nicht, wenn du in einem Jitsi bist
oder in einem Slack oder so, dann bist du ja immer mit allen
Leuten gleichzeitig am Sprechen
und das ist zwar schön, ja, weil
du mit allen Leuten gleichzeitig sprechen kannst, aber es ist auch
so ein bisschen erschreckend, weil dir alle Leute immer
zuhören, ja, weil alles public ist.
Ja und außerdem meinte ich, die Leute reden vielleicht dann gar nicht,
weil irgendwer immer redet halt. Ja genau, weil man sich
nicht traut.
Oder man kann an den Stand gehen von den Sponsoren
und kann sich da was zeigen lassen.
Oder man kann sich an den Tisch setzen, wo schon vier Leute sitzen
und dann weißt du, es sind genau vier Leute da und nicht 80.
Und das macht einfach ein ganz nettes Gefühl.
Also man kann eigentlich gar nicht so richtig viel kritisieren,
außer eben die Bildqualität.
Jochen, du hast alle Talks angeguckt, oder?
Ja.
Was war denn der Talk, der dich am meisten überrascht hat?
Tatsächlich der erste, würde ich sagen. Insofern ist das ein bisschen langweilig immer.
Dann sprechen wir da nicht nochmal drüber.
Genau. Ansonsten fand ich die, also man muss auch unter, also ich meine, es gab halt, es gibt halt mehrere Dimensionen sozusagen. Es gab halt Text, Talks, die mich halt irgendwie inhaltlich überrascht haben, irgendwie so wie die.
der erste und die ich auch gut fand. Oder es gab
welche, die ich technisch gut fand.
Oder es gab welche, wo ich
den Inhalt fachlich super fand.
Aber das muss alles nicht unbedingt
gleichzeitig passiert sein, sondern das war
teilweise, ja. Hast du vielleicht noch
eine Empfehlung von einem Talk, den man unbedingt gucken sollte,
wenn du jetzt mal drauf bist? Also einer
meiner Lieblingstalks war auf jeden Fall
der von Carlton Gibson.
Static Sides.
Das ist auch generell großartig.
Static Sides mit Zwings, weil
ich hatte auch selber da schon mal so Dinge gemacht.
Ich habe auch überlegt, ob ich da nicht irgendwie
Viewpress oder
Whitepress, ich habe da schon
auch Dinge mitgemacht, für Dokumentation
von Software verwenden soll.
Und dann
dieses, diese
Read the Docs
Geschichte, wie heißt das noch da?
Restructured Text, das ist ja eigentlich auch ganz nett,
da kann man auch viele schöne Sachen, aber es ist meistens nicht so
vielleicht unbedingt
hat eben auch Vor- und Nachteile.
Und das, was er da vorgestellt hat, das fand ich schon
großartig, dass man halt sozusagen auf der einen Seite
diese etablierte
Dokumentations-
Erstellungsgeschichte benutzen kann, aber auf der
anderen Seite dann halt, das war mir auch völlig
überhaupt gar nicht klar, dass die Django-Dokumentation das so macht,
dass da nicht ein fertig
gerendertes statisches HTML ist,
sondern dass das dynamische Elemente hat und dass das halt
sozusagen die Art, wie
der Dokumentations-Content
in die Django-Dokumentationsseite reinkommt,
ist halt über JSON.
Das war mir überhaupt nicht klar
und das ist eigentlich aber voll gut.
Total absurd.
Und deswegen, also den Talk fand ich
auch technisch gut. Also das Audio war
super. Carlton macht das auch total
gut. Er ist total entspannt und
ein bisschen flapsig und kurz und
echt cool. Carlton Gibson
Static Pages, ja.
Carlton Gibson ist generell so einer, der in der
Community ganz viel macht. Er ist
einer von den Django Fellows.
Der macht die ganze Drecksarbeit.
Er bezeichnet sich selbst als Janitor.
Django ist Janitor.
Und
der ist schon
jahrelang in der Community
drin und der ist großartig. Also das kann ich jedem
empfehlen. Oh, er macht ja auch einen Podcast
mit Will Winston zusammen,
Django Chat. Ach, das ist auch gut.
Hatte ich kürzlich im Auto die Zeit, acht Episoden
anzuhören.
Also auch das, da muss man die Konkurrenz
einmal hier hervorheben. Du hast ja demnächst
öfter mal Zeit wieder für die Podcasts
in einem Auto, habe ich gehört. Ja, es kann
passieren, dass ich demnächst mehr Auto fahren muss.
Der Talk, der mich am meisten
überrascht hat, wusste ich aber
vorher schon, weil ich kenne die Person auch
von anderen
Django-Cons, wo ich schon war, ist
Rewriting Django from Scratch in 2021
von Emma Deliscore,
die sich die Frage gestellt hat, wenn wir
kein Django hätten
und es aus
Bibliotheken zusammensetzen müssten, wie
schwierig wäre das denn?
Und die Antwort ist, erstaunlich wenig.
Ja, wäre gar nicht so schwer.
Ja genau, man findet quasi für alle Bauteile
was und sie hat dann eben wenige
hundert Zeilen Glue-Code geschrieben,
die das Ganze zu einem Django machen und
das so als Denkanstoß für Django
4, weil das steht ja demnächst
an, wo
wohl auch einige technische Änderungen drin sein sollen.
Fand ich super spannend.
Ja, ja, aber ich meine,
also in gewisser Weise wäre
das, aber das kann auch sein, dass ich das nicht so
richtig verstanden habe, weil ich dachte so
erst so, ja, interessant, die ganzen
Dinge, die sie da nennt, aber warum sollte man das so machen, weil
für mich ist ja eigentlich der Vorteil
von Django jetzt gegenüber, zum Beispiel
sowas wie Flask oder so,
oder könnte man auch gleich nochmal kurz was zu sagen,
dass man
das eben nicht machen muss, dass man auch
nicht sich daran kümmern muss, dass die ganzen Sachen
immer noch gemaintained sind und wenn sie
das nicht mehr sind, das austauscht, sondern Django kriegst du
sozusagen das Komplettpaket, wo andere Leute sich
darum gekümmert haben, vielleicht nicht
alle Funktionen und nicht so
im Detail ausgefeilt,
aber dafür halt irgendwie
Stimmig. Integriert. Genau.
Integriert. Ja, aber
was wäre denn, wenn Django nicht ein
Paket wäre, sondern wenn Django ein Meta-Paket wäre,
was zwölf andere Pakete
reinzieht, wo wenn du
Django installierst, kriegst du es immer noch integriert
und immer noch stimmig, aber hast
dann trotzdem die Möglichkeit, einen Baukasten
zu haben. Hast trotzdem die Möglichkeit zu sagen,
ah, Moment mal, ich möchte eigentlich lieber
Templates haben, die x machen oder Templates
die y haben. Ja. Oder auch
eben so Contrib-Pakete. Was ist denn,
wenn ich mal den Admin nicht brauche?
was ist denn, wenn ich mal eine Seite habe, die den Admin
nicht braucht? Im Moment kann ich ja
nicht viel machen. Ich kann die App
deaktivieren und ich kann die URLs deaktivieren.
Aber der Code ist auf jeden Fall drin, ja.
Aber der Code ist immer noch da.
Und sich diese
Frage zu stellen, was wäre denn, wenn Django
modular wäre? Es ist ja modular,
es ist ja jetzt schon so, dass du die verschiedenen
Bausteine miteinander kombinierst,
aber was wäre denn, wenn die auf technischer Ebene
auch modular wären?
Was im Django-Chat gesagt wurde, was wäre
denn, wenn man manche Pakete einfach ein bisschen
ausgliedern könnte?
Carlton Gibson möchte gerne das E-Mail-Paket
ausgliedern.
Was wäre denn, wenn
das möglich wäre? Und was wäre denn, wenn sich da
vielleicht ein eigener Maintainer dafür findet, der
E-Mail macht?
Was wäre denn, wenn es
ein E-Mail-Paket gibt, was automatisch alles
macht, dass ich über SendGrid
verschicke?
Ich muss nur PipInstall, Django, SendGrid machen
und dann ist das komplett nah.
Diese Frage ist
Das ist eine großartige, gute Frage.
Okay, ja, gut. Also so gesehen doch,
ja, weil im Grunde ist Django
ja schon, da sind viele Teile sind ja schon
pluggable, eben Storage oder halt
Authentication, halt nicht auf so einer
ich installiere dann halt ein anderes
Paket, sondern auf der Ebene von
in den Settings sage ich halt, ja,
du bist jetzt für mehrere Pakete
und dann stelle ich es in den Settings ein, welches benutzt
wird. Genau, aber
stimmt, also dass man
den Code gar nicht mit drin haben muss, das ist natürlich schon so ein
Punkt, ja.
Das ist aber auch noch
interessant. Genau, jetzt fällt mir doch noch
was ein, zu welcher Talk hat mich am meisten
überrascht. Und zwar, ich weiß nicht, ob ihr den
oder Johannes, ob du den auch gehört hast,
von Jannis Leidl,
der Jazzband
Talk. Ja, habe ich gehört.
Ich bin auch live während des
Talks Jazzband beigetreten.
Ah, okay, genau. Ich habe es mir nur überlegt,
ich habe es noch nicht getan, aber ich
habe stark daran gedacht, es zu tun.
Und
genau, ich hatte das immer nur gesehen.
Was ist denn Jazzband, Jochen? Erklär mal.
Ich hatte das immer nur gesehen bisher als
das ist irgendwie eine Organisation,
in der viele der im Django
Kosmos befindlichen
Pakete halt so auch mit drin sind
und was da gemantet wird,
Django Filter und weiß ich nicht,
ganz, ganz viel Zeug.
Storages und Comments.
Also ganz
viel und da dachte ich immer so, ja.
Und dann wusste ich auch irgendwie so, ja, das ist halt irgendwie so, wenn man
keine Lust mehr hat, das selber zu mantennen, dann kann man das vielleicht dahin
das loswerden.
Projekthalde meinst du?
Irgendwie, weiß ich nicht,
ein Schleifchen dran binden und das dann da aussetzen.
Wie an der Autobahnraststätte.
Die Apache Foundation der Django-Welt.
Ja.
Aber genau.
Die sind ja tatsächlich sehr aktiv,
habe ich jetzt gehört in dem Talk.
Ja, aber dann,
was mich in dem Talk dann halt überrascht hat und was ich nicht wusste,
ist, dass
das tatsächlich etwas ist, wo man
selber sehr leicht beitreten kann
und
man hat so ein bisschen die Anforderungen an ein Projekt,
aber es ist auch relativ leicht zu erfüllen
und dann kann man
quasi Projekte davon maintainen lassen
und also der entscheidende Punkt, und der war mir überhaupt
nicht klar, ist
bei diesen Projekten ist es so, dass man das so ein bisschen
umkehrt, weil normalerweise hast du halt immer
in vielen Projekten irgendwie so
Core-Entwickler oder Leute, die halt
da reinkommitten dürfen, also dieses
Privileg bekommt man halt
Normalerweise, weiß ich nicht, nach ein paar erfolgreichen Pull-Requests oder so oft bei vielen Projekten. Und vielleicht bei so noch größeren ist es so, dass es dann Leute gibt, die dann überwiegend, ja, sich um den Issue-Tracker kümmern oder sowas. Und es gibt halt einen Unterschied zwischen diesen sozusagen offiziell Beteiligten und den ganzen Leuten, die halt tatsächlich die Pull-Requests erstellen.
Und dieses Jazzband dreht das halt um und sagt, du kannst halt einfach da reinkommitten. Es funktioniert halt. Und dann muss, es gibt halt nur weniger Release.
Und jeder kann beitreten.
Jeder kann beitreten und erst beim Release wird dann halt geguckt, okay, macht das denn irgendwie Sinn oder ist das irgendwie Quatsch? Und das passiert halt deutlich seltener, sodass du halt diese Hürde, das ist tatsächlich eine Hürde, das habe ich mir auch schon oft gedacht, muss ich das jetzt wirklich?
Ja, und ein Pull-Request stellen und dann
hörst du acht Wochen lang nichts und dann
fragst du, ja hier ist was und dann weißt du es schon alles
gar nicht mehr oder geht ganz unter.
Ja und was ich dann oft mache ist,
ach dann fork ich es doch mal schnell selber, fix das
da und dann
dann vielleicht mache ich doch tatsächlich
nochmal ein Pull-Request, aber eigentlich auch egal
und tatsächlich habe ich das
auch bei Projekten gemacht, die in Jasmine da
drin sind und dann hätte ich dann so, okay
eigentlich hätte ich die direkt fixen
können und
dann wäre dieser ganze
ja, hätte man diesen ganzen Tanz
um GitHub-Pull-Request-Issue gar nicht
machen müssen, sondern jetzt einfach gefixt, committet
und fertig. Was heißt bei Django
Field-Hastorisches All-Outs?
Django Field-Hastorisches All-Outs? Ja, ganz viele von diesen Sachen,
die man kennt, ich glaube auch Django Extensions und
Debug-Toolbars sind inzwischen Jazzband-Projekte.
Ja. Oh, apropos
Debug-Toolbar, da gab es ja auch was für das.
Der Jazzband, weil
das irgendwie sozusagen,
ja, Django ist ja auch vom Namen her
wird das zurückgeführt
auf dem Django rein hat.
Ach so. Ja, daher kommt das.
Und Band. Cooler Name,
finde ich. Ja.
Django Extensions, hast du noch irgendwas Schönes
geteilt, Johannes? Und zwar hast du
da was entdeckt, das heißt die Kolo-App
heißt, was auch für Debug
für Django relativ lustig sein soll.
Da musst du mir auf die
Sprünge helfen, Dominik. Weiß gar nicht, was du meinst gerade.
Du hast das schon schon hingeteilt.
Kolo-App, das ist eine Django-Applikation
zum Debuggen. Vor allem auch in VS Code
Grundsätzlich. Du kannst halt so den
Thor Street anschauen.
Genau, das hat mich jetzt
gar nicht so richtig, hat mir gar nicht so richtig
geholfen, weil ich VSCode nicht benutze.
Aber
die haben eben einen Django-Debugger
in VSCode integriert und zwar so richtig tief.
Also der zeigt einem direkt alle Innereien.
Genau, Best Response,
die Queries und so.
Genau, und auch mit Profiling drin und wenn
Fehler auftreten, kommst du gleich an eine richtige Stelle.
Genau, man kann sogar den Executed-Code-Path
visualisieren und so.
Es ist ein richtig, richtig ausgefeilter
Debugger, geht allerdings nur in Visual Studio Code.
Also Celery Task kann man damit machen.
Also der zeigt
dann wirklich alles an und das ist sehr beeindruckend.
Ja, ich habe es leider
nicht weiter benutzt, weil ich bin
ja, ich komme ja aus einer anderen Richtung.
Charming.
Ich bin sehr charming.
Ja.
Auch was, was ich da gesehen habe. Okay, ich habe noch eine andere
Sache, die mich überrascht hat da.
Bei der DjangoCon.
Und das war HTMX.
Oh ja. Du hattest das schon mal
erwähnt, Jochen. Ja.
Du hattest HTMLX schon mal gesagt.
HTMLX ist eine JavaScript-Bibliothek
ohne JavaScript.
Das heißt,
anstatt dass ich selber JavaScript schreibe,
schreibe ich nur spezifische
Tags an meinen HTML dran,
die dann irgendwelches dynamisches Verhalten auslösen.
Zum Beispiel kann ich einem Button sagen, dass er
das Formular submitten soll.
Oder ich kann sagen, wenn
ein Item
in den Bildschirmbereich gescrollt wird,
dann macht das ein AJAX-Request
und holt neue Listen-Einträge
und kann ich Infinite Scrolling machen.
Oder ich kann sagen,
ich möchte Formvalidierung haben
oder ich kann sagen,
ich möchte Animationen haben oder so.
Und das Ganze nur über HTML-Tags,
ohne selbst JavaScript schreiben zu müssen.
Und das kam in drei oder vier Talks hintereinander.
Haben sie alle auf HTMLX verwiesen
und offensichtlich auch nicht abgestimmt,
weil die dann, die Sprecher dann auch gesagt haben,
ja, es ist jetzt schon wieder, ich weiß,
es kam jetzt eben schon in den anderen Talks, aber jetzt ist es schon wieder.
Und auch im Slack
kam das dann auf,
dass da jetzt schon wieder
HTMX vorkommt.
Und ich glaube, das ist was, was ich mir,
also ich wusste, dass es das gibt,
aber mir war gar nicht so klar
gewesen, wie sinnvoll das ist und wie nützlich das ist.
Und dass man ja tatsächlich
sehr viel Dynamik in seiner Seite mit
diesen einfachen Mitteln hinkriegen kann.
Also das, wo man früher
jQuery verwendet hat, ja,
Button.click
und dann $ajax
machen, ist jetzt einfach
in dieses htmx-Attribut
reingewandert. Und
ich glaube, ich muss mir das mal noch
genauer angucken,
wie weit man da gehen kann.
Also, ich meine, einen Talk gab es
damit, der hat es quasi zu Ende gedacht.
Was ist denn, wenn wir diese Sachen alle aus dem
Django-Form, aus der Form-Klasse
generieren und aus dem Django-Modell generieren?
auch großartige Idee,
Data-Binding automatisch erzeugen
über Django-Template-Syntax.
Geht vielleicht einen Schritt zu weit.
Möchte ich schon noch die Kontrolle drüber haben.
Aber, ja, dass man quasi JavaScript schreibt,
ohne JavaScript schreiben zu müssen,
großartige Idee.
Ja, ich habe letztens,
ja genau, würde ich auch sagen,
das war auf jeden Fall auch eines der großen Themenfelder,
die es auf der Django-Con gab.
Nämlich, wie macht man eigentlich,
sozusagen, ja,
etwas interaktivere
oder so modernere,
so Single-Page-App
mäßige
Applikationen mit Django, weil
wohl auch der Druck größer wird irgendwie von da
außen. Und vielleicht kann
man aber, muss man dafür nicht jetzt irgendwie
das, also es gibt einen Weg,
den halt auch viele Leute beschreiben,
beschreiten, der ist halt, naja, du machst halt
Django REST-Framework oder halt, weiß ich nicht,
GraphQL irgendwie, Graphene. Gab's auch einen Talk dazu.
Ja, und machst halt deine
Applikationen im Frontend halt
quasi als, weiß ich nicht, ReactView
Angular. Django Headless.
Und Headless, genau. Und
dein Backend ist sozusagen, dein Django ist halt nur noch
das Backend und macht halt, rennt halt nur noch
JSON raus und sonst nichts.
Das ist eine Möglichkeit. Das ist aber eigentlich irgendwie
traurig, oder? Das ist irgendwie traurig, weil
man die ganzen guten Teile halt
Ja, es gibt halt schöne Teile
von Django, eben die
Formulare, ja, Formvalidation oder so,
das kann man halt alles nicht mehr nutzen. Template,
Da gibt es sehr schöne Geschichten für.
Authentifizierung auch, alles mögliche.
Genau. Man verliert halt
viele Dinge, die halt bei Django
eigentlich total nützlich machen.
Und die muss man dann selber machen. Und wenn man das
dann macht in JavaScript, stellt man oft fest,
äh.
Ja, man schreibt sich halt
die langweiligen Teile von Django,
schreibt man sich dann in JavaScript nochmal nach.
Genau. Und das ist halt...
Und man hat dann immer noch
eine andere Programmiersprache, die man halt auch noch mit
kämpfen muss. Und das ist halt...
Aber mit JavaScript muss man doch.
Deswegen nimmt man ja TypeScript.
Ja, also es ist besser geworden,
sagen wir mal so. Aber
ehrlich gesagt, mir ist Python
immer noch lieber, auch die ganzen...
Auch angenehmer. Ja, ja, durchaus.
Und eben,
was kann man denn jetzt eigentlich noch tun?
Da gibt es ja dann mehrere Gegenbewegungen, aber
wir hatten das ja auch schon ein paar Mal,
sowas wie dieses ganze
Hotwire-Zeugs,
irgendwie Ruby on Rails macht das ja auch,
dass man halt sozusagen, oder Elixir,
Felix,
man rendert halt HTML
auf der Server-Seite und
hat nur noch wenig JavaScript auf der
Client-Seite, was halt dann irgendwie
die Seite updatet. Und
tatsächlich fällt für mich HTMX halt auch in
diese Klasse von Dingen rein.
Oder, sagen wir mal so,
jQuery scheint jetzt wohl dann so
endgültig irgendwie tot zu sein.
Ja, das ist ja
mit ECMAScript 6 sind ja die
meisten Sachen, für die man früher
jQuery benutzt hat, einfach direkt in VanillaJS
drin und dann...
Genau, genau. Und es gibt dann
im Grunde, entweder verwendet man halt, wenn man noch mehr
JavaScript machen möchte,
dann sowas wie AlpineJS oder so.
Oder halt eben HTMX, wenn man nichts kompliziertes
macht oder wo da auch schon einige interessante
Sachen gehen. Und ich habe jetzt letztens auch
eine Podcast-Episode gehört mit dem Auto
von HTMX.
Und
der beschrieb so ein bisschen, was er damit vorhatte
und das fand ich auch sehr interessant, weil das hat mich tatsächlich
an die Episode, wo wir
das letzte Mal zusammengesetzt haben, REST
erinnert.
Da haben wir auch das
erste Mal HTMX erwähnt.
Und
dass das Ding HTMX nennt, heißt,
das ist kein Zufall. Das ist
tatsächlich, meinte er,
er hat aber mit jQuery angefangen und dann
hat er sich überlegt, okay, eigentlich ist das ja blöd.
Und
hat dann versucht, die Funktionalität,
da hat er irgendwie das
Gefühl, das müsste ja eigentlich in HTML
oder so drin sein und das bricht ja auch mit
ist ein ganzes REST-Ding. Und da hat er
wohl auch die Dissertation von Roy Feeling
da gelesen. Und er meinte so, was wäre denn,
wenn ich eine Bibliothek schreiben würde,
die es erlaubt, dass
das irgendwie so ist, wie das eigentlich sein
sollte, aber
man selber das JavaScript dafür
nicht schreiben muss. Also ich erweitere sozusagen
HTML
so, wie das eigentlich gehören würde,
wenn es Browser-Supporter für gäbe. Und das mache ich dann halt
in JavaScript. Und das Ding nennt er irgendwie
Intercooler.js. Und das war am Anfang noch so
ein bisschen grude und sehr Jackfairy-mäßig.
Ich habe schon mal davon gehört.
Auch noch gelobt heutzutage.
Er meinte, der Name ist halt schlecht,
weil das JS hinten dran
vermittelt den Eindruck,
das wäre eins von diesen JavaScript-Frameworks,
was es eigentlich nicht ist von den Frameworks.
Und Intercooler versteht auch keiner.
Und dann hat er so ein bisschen
so ähnlich,
wie nennen wir diesen Podcast?
Na ja, gucken wir mal.
Eigentlich möchte ich
HTML, aber erweitert, extended.
htmx, okay, htmx-org noch frei,
oh, super. Und dann
ist das Ding halt htmx.
Und die Idee ist...
Die Buchstaben org-demands ist auch nicht schlecht.
Ja, gibt's eigentlich gar nicht mehr so häufig, aber
hat wohl funktioniert.
Und deswegen hat er das dann halt
jetzt nochmal so, ist halt sozusagen Nachfolger
von intercooler.js.
Und die Idee ist tatsächlich,
was wäre denn, also was
ist das Hauptproblem bei, wenn man jetzt
einfach nur ganz stinknormal
html rendert und
dieses HOS
verwenden möchte, also
Hypermedia ist die Engine of Application
State-Dings und so quasi die
Prinzipien beibringen möchte,
die halt auch in dieser Dissertation
von Roy Fielding drin sind.
Also das Hauptproblem, weshalb das nicht
gut ist und weshalb alle irgendwie
JavaScript zusätzlich machen, ist, dass
sobald du irgendwas änderst
in diesem alten Modell, musst du
deinen kompletten DOM neu aufbauen,
also einen Request-Response-Type
einen kompletten Page Reload. Ja, du musst einen kompletten Page Reload
machen und das ist halt etwas, was
nicht gut funktioniert, weil das
ist halt für, wenn die Seite komplizierter wird,
dann dauert das halt einfach schon mal über eine Sekunde,
bis sich die Seite wieder aufgebaut hat und das
heißt irgendwie alles, das fühlt sich dann einfach
nicht mehr flüssig an und das ist halt
ja, aber
mit AJAX und so
konnte man ja da immer schon so ein bisschen was machen, so
Web 2.0 mäßig und
aber das ist halt eben dann eben
und jQuery, aber das ist halt eben nicht
REST eigentlich.
Und auch diese Single-Page-Apps sind auch nicht REST, weil die sagen, okay, naja, der Application-State ist halt im Frontend und Backend liefert halt nur Daten oder vielleicht so ein bisschen State, aber du hast halt dieses Synchronisationsproblem, aber die eigentliche Applikation läuft halt im Browser.
Und er meinte, okay, wie ist es denn, wenn wir jetzt sagen, okay, wir erweitern HTML eigentlich um die Elemente. Warum ist es so, dass nur Form, nur das Form-Tag einen Post auslösen kann? Warum kann das nur einen Post auslösen? Warum gibt es nichts, was irgendwie einen Put auslösen kann?
Ja, okay, aber gut, man kann das ja einfach dann so machen, weil aus JavaScript heraus kann man das ja dann tun, dann führt man halt Attribute ein, wo dann Elemente eben auch einen Put machen können oder halt eben auch andere Elemente einen Post machen können und dann kommt dabei, wenn man das dann halt sozusagen so ein bisschen standardisiert, kommt halt HTMLX eigentlich raus, sodass du halt sozusagen diese ganzen anderen netten Sachen halt auch einfach nur in deinem HTML sozusagen machst und ja, es gibt halt dann noch so eine Bibliothek, die das, solange die Browser das nicht unterstützen,
halt dann für dich in JavaScript tut,
aber im Grunde könnte man das auch einfach so...
Ja. Und das ist
eigentlich ein sehr, sehr
interessanter Gedanke. Also fand ich auch sehr gut.
Ja.
Ja, und es kam einfach so häufig
vor. Ja. Ja, also man merkt,
dass man gezwungen war, sich das anzusehen. Also es
scheint irgendwie jetzt so im Zeitgeist drin zu
sein oder eben im Gedanken
der Moment, das Moment ist...
Ja, der Zeitgeist geht auf jeden Fall Richtung
ja, was wäre denn, wenn wir einfach HTML
rüberschicken und nicht irgendwie JSON
So ein bisschen, ja.
Na gut, diese ganzen Single-Page-Apps,
so eine React-App oder so eine Angular-App
oder so eine Ember-App oder was auch immer,
sind ja im Wesentlichen gar keine Webseiten.
Das sind ja Desktop-Anwendungen,
die halt, okay, zufällig in so einer VM laufen,
die Browser und JavaScript heißt.
Und die aber im Wesentlichen ja selbstständig sind.
Und es geht ja bei vielen Sachen auch total gut,
dass du halt eine Anwendung hast im Vordergrund.
also es gibt ja inzwischen alle möglichen Sachen. Es gibt ja
Fotobearbeitungssoftware
im Browser.
Ja gut, also klar, wenn man...
Es braucht ja überhaupt gar keinen...
dass das Internet da ist.
Wenn man so eine Applikation hat, die selber sehr viel macht
und die ab und zu, wo vielleicht man mit dem Backend reden muss,
okay, dann ist das dafür vielleicht
auch super geeignet. Aber ich meine,
die meisten Webseiten sind ja gar nicht unbedingt so.
Genau, deshalb meine ich das ja.
Das meine ich ja.
Es gibt ja ganz viele solche Anwendungen, die halt
einfach Desktop-Anwendungen sind, die
die zufällig im Browser laufen.
Und es gibt aber auch
sicherlich den größeren Teil
der Webseiten, die halt
die gerne so wären,
aber es eigentlich gar nicht nötig haben.
Und so diese Brücke
dazwischen zu schaffen,
ist glaube ich,
das ist eben das, weshalb es im Zeitgeist ist,
dass man jetzt eben von den ganz statischen
Webseiten, sind wir ja schon lange
weg oder sind wir ja schon auf eine gewisse
Art und Weise lange weg, die ganz dynamischen
Sachen, die ja eigentlich Anwendungen sind,
selbst freistehende Anwendungen, die
zufällig halt auch noch Internet-Requests machen.
Das ist die
andere Seite und eine Weile lang hat man versucht, das alles,
ja, alles muss so eine Anwendung sein,
was aber auch nicht sinnvoll ist.
So auf den Zwischenschritt zu gehen,
dass du eigentlich eine, dass du statische Informationen
anzeigst, die aber trotzdem irgendwie auf
Events reagieren können und sich dann trotzdem so ein bisschen
zumindest verändern können,
ist, glaube ich,
einfach, ja, das ist der
Kompromiss in der Mitte und der deckt
sicherlich da super viele
Use Cases ab und super viele Sachen
ab, die man eben früher entweder
so oder so machen musste und deshalb
ja,
in die Mitte ist richtig.
Das Nash-Gleichgewicht
ist immer in der Mitte.
Wie heißt es bei
Alexander Kluge, glaube ich,
in Gefahr und großer Not,
es bringt der Mittelweg den Tod.
Ja, aber in der Mitte der Herde
zu sein, ist der sicherste Ort, deshalb
Ja, genau. Zu der letzten Rest-Episode, da gab es dann auch eine Erwähnung im Podlovers-Podcast, wo es um die Entwicklung von so einer Podcast-Plattform geht, im Grunde, basierend auf WordPress und so einem Plugin. Und da wurde durchaus wahrgenommen, dass wir irgendwie über XML gelästert haben. So was.
Passt. Habt ihr euch
gerügt
worden? Ja.
Nee, es wurde sogar ein gewisses
Verständnis dafür gezeigt, dass Entwickler vielleicht doch lieber
Jason mögen, unter Umständen
als XML.
Was hat dir denn gefehlt
an der DjangoCon? Was müsste die DjangoCon mehr
haben?
Schwer zu sagen, also was mir
ich war jetzt
gar nicht so wahnsinnig da mit drin,
also ich würde sagen, was mir persönlich gefehlt hat, war halt
der Kontakt mit den anderen Leuten, aber das ging halt einfach nicht.
Aber da kann man jetzt keinen Vorwurf
machen. Ja, aber das ist halt der Grund,
warum man eigentlich das... Ja, also ich
würde auch sagen, eigentlich, wenn man vor Ort sein könnte,
ich wäre auch gerne mal nach Porto gefahren,
wo das hätte eigentlich stattfinden sollen.
Ja, das ist auf jeden Fall eine ganz andere
Atmosphäre, ne? Also wenn man da die ganze Zeit doch noch
wieder vor dem selben Rechner sitzt. Ja, und auch mehr
Fokus einfach. Ja.
Aber... Das ist ja
Vor- und Nachteil, ja.
Ich habe das auch sehr genossen, dass ich da nicht hinfahren
musste, weil ich konnte mich halt trotzdem um
meine Kinder kümmern, konnte trotzdem
dann abends mit der Familie
essen und dann trotzdem abends
noch die Talks. Als ob du es nicht genossen hättest, wenn du auch mal
ausnahmsweise ohne die Familie und ohne die Kinder
irgendwie frei in Porto.
Klar, hätte ich auch genossen. Wäre aber
einfach schwieriger gewesen,
das zu machen. Ich glaube,
ich glaube, in Zukunft wäre
das sehr schön, wenn solche Konferenzen so ein Hybridmodell
hätten. Dass man da sein
kann, aber dass man
auch online sein kann.
Okay, finde ich ehrlich gesagt ein bisschen
anstrengend.
Ja, mag sein, aber es sind einfach
unterschiedliche Zielgruppen und
es gibt ganz viele Leute, die können nicht
reisen oder die wollen nicht reisen oder die
haben das sehr schwer
zu reisen und machen es deshalb
entsprechend selten und ich glaube,
Online-Konferenzen ist was, was bleiben wird
und dann müsste man irgendwas,
ich habe da auch ganz eigene Ideen, ich finde es ganz
cool, dass es Online-Konferenzen gibt,
aber eigentlich, wenn man die Online-Konferenz macht,
dann braucht man keine DjangoCon EU und keine
DjangoCon India und
keine DjangoCon America, sondern es müsste eigentlich
eine DjangoCon Worldwide geben und
dann ist die Sache klar, ja, du kannst nicht
bei allen Talks dabei sein, aber du kannst halt bei denen dabei
sein, wo du dabei sein kannst und fertig.
Aber das ist mehr Umbruch
als
Also ich finde, das hat auch ein bisschen was familiäres,
wenn man da hingehen kann, kann die Leute wirklich treffen
irgendwie, wie kleiner das ist,
desto familiärer ist das und je größer es wird, desto anonymer wird das
und das Problem, was du ja gerade schon beschrieben hast,
an diesen Online-Talks ist halt vor allen Dingen
dieses Frontalunterrichtsthema, dass
irgendwie alle Leute einen Speaker in einem Raum hängen,
Und sich diese ganzen Nebengespräche halt nicht entwickeln,
sich diese ganze soziale Interaktion irgendwie nicht so
entwickelt, wie man sich das wünscht, man sich nicht mal gemeinsam Kaffee
trinkt, irgendwelche zufälligen Bekanntschaften
auf einem Gang hat oder so. Und das ist ja
auch das, wovon irgendwie so eine Community lebt und so.
Und das ist halt virtuell,
ja, vielleicht hast du sowas wie
Gather Town so ein bisschen
reproduzierbar, aber
naja, ist halt doch schon was ganz anderes, ne?
Ja klar, aber du schließt halt auch manche
Leute aus, die das nicht können oder nicht wollen.
Und die Leute sind auch ein
wichtiger Teil der Community.
die irgendwie mitnehmen und deshalb
denke ich, es wird
Mischlösungen geben in der Zukunft
und muss es auch geben. Okay, aber ich habe noch
was ganz Konkretes, was mir jetzt leider
gefehlt hat an der Konferenz
und das waren die Lightning Talks.
Es gab Lightning Talks. Oh ja, stimmt.
Und die waren auch alle sehr gut und
sehr schön und es war wirklich cool, dass da die Leute
sich, also ich kann das jedem nur empfehlen,
ja, das ist ein guter Einstieg, fünf Minuten, das
schafft jeder. Die waren
alle pre-recorded, das heißt, man hat auch nicht den
Stress des Live-Daseins
gehabt. Ich kann es jedem nur empfehlen.
Aber die Auswahl war dieses Mal
nicht so groß.
Es waren alles technische Talks.
Es waren auch nur eine Handvoll.
Und die
waren nicht so promoted, wie sie bei einer
Konferenz wären. Also so ganz cool,
wie baue ich mein Baumhaus, das hat denen noch gefehlt.
Genau, also ich habe einfach
in Heidelberg hat einer einen Talk gehalten,
wie baue ich ein Baumhaus?
Fünf Minuten Lightning Talk. Großartig.
Hatte überhaupt nichts mit der DjangoCon zu tun,
aber war großartig.
Es ist so ein bisschen so ungefähr der einzige Talk, an den ich mich erinnern kann von der DjangoCon 2019 oder 2018 war es, ich weiß nicht mehr. Einfach, weil es so was ganz anderes war und das gab es dieses Mal gar nicht.
Und das fand ich ein bisschen schade, dass es da nicht mehr so ein bisschen drüber hinausging, weil es war schon sehr fokussiert auf Django, was ja okay ist, aber bei den Lightning-Talks darf man durchaus, finde ich, auch so ein bisschen über die Stränge schlagen und das hätte ich mir mehr gewünscht.
Ja.
Das ist keine Kritik an jetzt irgendjemandem,
sondern das ist eher Kritik an jemandem, der nicht dabei war.
Schämt euch was. Ihr hättet
dabei sein sollen und hättet coole Talks über
abgefahrene Dinge halten können.
Jeder hat ein Hobby und jeder kann das fünf Minuten
präsentieren. Das interessiert ganz viele Leute.
Meine Hobbys sind alle illegal.
Meine Hobbys
sind Python und Django, deshalb
ich bin da schon
ertappt.
Ja.
Ja, ansonsten.
Das ist ein Bereich.
Ja, stimmt. Also das hat mich auch gewundert,
dass ich die Lightning-Talks war,
schon vorbei, hupsala.
Ja, waren zu wenige und waren auch nicht
divers genug, sagen wir mal so.
Ja, ansonsten so große, große Themen.
Wir hatten jetzt so, genau, dieses ganze
HTMX,
so, genau,
das war auf jeden Fall ein großes
Thema, gab es viele Talks zu,
viele Talks gab es halt auch zu
Datenbank-Geschichten,
das fand ich auch voll gut, also da waren auch einige,
ja, eben diese. Der von Haki Benita,
großartig. Ja, Markus Holtermann auch.
Let's use another index.
Ja. Can we do better?
You've been in this talk long enough to know that yes,
we can do better.
Ja, oder auch der, wie macht man
Migration eigentlich ordentlich, wenn man ein Produktionssystem
hat, das irgendwie vielleicht nicht so
verträgt, wenn man da mal, das fand ich auch
sehr gut. Ich meine, klar.
Was können wir denn machen, ohne den Django ORM zu benutzen?
Was ist denn, wenn wir nur SQL benutzen wollen?
Auch super. Ja, fand ich auch gut, weil
dass das geht, war mir schon klar und
ich habe das auch so ab und zu gemacht, aber was man da alles
machen kann, das war mir jetzt gar nicht so präsent und das war
ja, das war auch super. Und das
SQL ist ja eigentlich auch eine sehr interessante
Geschichte, dass man viel
in SQL machen kann.
Da kann man eine eigene Episode machen.
Ja, drüber.
Ja, ja, ja. Und Postgres wird immer besser.
Ja, Postgres wird so langsam
zur Eier legenden Wollmilch, aber das kann alles.
Ja, das war auf jeden Fall auch ein
großes Thema.
Ja, dann, was hatten wir denn
noch an größeren, dann
GraphQL, war halt auch
ein großes Thema,
aber auch vor allen Dingen in Kombination,
in einem Talk gab es, fand ich,
im Zusammenhang
mit Domain-Driven
Design
und genau.
Sehr gut. Genau, aber da
war auch, das muss ich, ja, es ist halt
tatsächlich nicht so ganz einfach, das
miteinander zu verknüpfen. Da wäre
auch nochmal interessant gewesen, wie du
das in dem dritten Teil, der da nicht vorgekommen ist.
Achso, der ist ja in der
Aufzeichnung.
Genau, wie macht man das eigentlich,
wenn man jetzt
irgendwie
Business-Logik hat, wo packt man die denn
jetzt in Django eigentlich hin,
wenn doch viele sagen, dass
gar nicht so gut ist, das in die Models zu packen.
Server, Helpers, Services,
Helpers, Utils.
Jochen, da haben wir doch schon
drüber gesprochen, wenn du das in die Models packst,
ist überhaupt nicht solid. Die sind überhaupt
nicht mehr Single Responsibility,
die sind überhaupt nicht mehr ersetzbar, die sind überhaupt nicht mehr
Ja.
Jede Buchstabe von Solid ist direkt
ist direkt
verletzt. Aber ja, das Problem
ist halt, andererseits auch irgendwie
nicht, weil das andererseits ist
Es ist halt auch schon sehr praktisch, das ist auch richtig.
Aber da, auf jeden Fall
mich kam darauf, weil sich auch, glaube ich, eben
in dieser Domain-Driven-Design-Plus-GraphQL
Geschichte hat sich auch, oder vielleicht war es
so ein anderer, vielleicht kriege ich es auch mal so richtig zusammen,
Talk, hat sich auch jemand dann so, ja, wie macht man
das eigentlich mit Django? Und dann, okay,
irgendwie geht es nicht so richtig gut, weil
wenn man es in die Models
schreibt, dann hat man da etwas,
macht man da etwas, was man eigentlich nicht tun sollte
und ja, aber anders geht es
irgendwie auch nicht gut und
Ja, das ist einfach so eine
ungelöste Frage.
Da ist auf jeden Fall noch eine Baustelle
und ich fand, man hat diesmal auch gemerkt, dass
die ordentlichen Menge,
ordentlichen Anteil der Leute tut es halt weh,
aber es gibt irgendwie keine Lösung, keine jedenfalls
keine Best Practice, die man einfach so verwenden
könnte.
Das ist so ein bisschen
der letzte Punkt, den ich bringen
möchte, der letzte Kritikpunkt, den
ich bringen möchte.
Die Django-Community ist großartig.
Die ist ganz große Klasse und
es gab quasi nichts,
wo ich irgendwie negative
Erfahrungen machte. Es gab nichts, wo jemand
ausgelacht wurde oder wo
ein unangenehmer Witz gemacht wurde oder wo
irgendwas negativ betrachtet wurde, sondern es ist
alles großartig und positiv.
Und das ist großartig, ja, das ist super für so eine Community
und ich bin da echt froh
und dankbar, Teil so einer Community
zu sein und jetzt nicht irgendwo
so in so einer
giftigen Community
festzustecken, die alle fertig machen.
Also ja, das ist wirklich großartig.
Und auch, dass
es geschafft wurde, dass viele
Frauen dabei sind, ja, auch
vielleicht nicht binäre, die waren jetzt, die standen jetzt
hier nicht irgendwo im Vordergrund oder so, aber
das wäre überhaupt gar kein Thema gewesen, ja.
Wäre überhaupt gar kein Thema gewesen.
großartig, ja, großartige
Community, sehr inklusiv, sehr, sehr
positiv, aber
aber auch
an manchen Stellen einfach ein bisschen zu positiv.
Zu wenig
über die schlechte Bildqualität wurde mal geredet,
das mal. Ja, das meine ich gar
nicht, sondern
Django, es wurde auch auf der Konferenz
mehrmals als the boring old framework
bezeichnet und
das ist was, was man Django
und der Community vorwerfen kann, ja, die Innovation
kommt aus anderen Sachen.
Die innovativen Sachen kommen aus
der Ruby-Welt, die viel kleiner ist.
Aus der Rails-Welt.
Die innovativen Sachen kommen aus der JavaScript-Welt,
die halt, ja okay,
die halt tun müssen, ja, weil sie
nicht anders können.
Aber warum haben wir
denn nicht so
viel Innovation in der Django und in der Python-Welt?
Warum
beäugen wir die Sachen nicht auch mal viel skeptischer
und sagen, ja, das ist ja schon ganz gut, aber
es könnte noch viel cooler sein?
So ein bisschen sieht man das ja mit dem HTMLX und mit dem Fullstack without writing JavaScript. Aber das sind immer nur Sachen, die, wir zeigen jetzt mal eine Lösung, die jemand gemacht hat.
es gab wenig so
lasst uns doch mal Folgendes machen oder lasst uns mal
ausprobieren oder hier ist was, was ihr noch nie gesehen habt.
Weil es das noch nicht gibt
irgendwo anders. Und ich hatte
das Gefühl, oder ich habe schon länger das Gefühl,
dass die Django-Community eben so ein kleines bisschen
weniger
ja, es ist schwer, das in Worte
zu fassen, ohne zu negativ zu sein.
Das ist einfach so gut, dass man einfach den Nied nicht hat,
sich so schnell in eine andere Richtung zu bringen.
Ja, vielleicht.
Ja, aber das ist ja so ein lokales Maximum, ja. Vielleicht ist das ja so. Vielleicht ist ja Django so ein lokales Maximum, wo es eben sehr schwer ist, sich rauszuoptimieren, weil jeder Schritt nach draußen erstmal ein Schritt nach unten ist. Und vielleicht ist es das, aber ich würde es mir halt wünschen, ja.
Ich habe in der Rails-Welt
total coole Sachen gesehen.
Hotwire kommt, glaube ich, aus der Rails-Welt.
Es wurde mehrmals darauf verwiesen,
wie Rails das macht, während Konferenztalks.
Und das ist schade,
weil Django sollte der Vorreiter sein.
Django ist nicht der Vorreiter. Django ist die
beste Lösung, aber nicht der Vorreiter.
Auf der anderen Seite ist Django
damit natürlich auch so ein bisschen wie Python selber.
Irgendwie so das zweitbeste
Framework.
Und es ist der absolut beste Platz, wo man sein kann,
der zweitbeste zu sein, weil der erste wird immer
angegriffen und sie zerlegt.
Mach doch mal, Johannes, sei doch mal innovativ.
Bring doch mal was Neues raus.
Ja, ich versuch's ja.
Ich versuch's ja, aber
erst mal muss ich Geld verdienen.
Ja, da kommt wieder her
der Greed und so.
Ja, ja, ja.
Diese Sache mit
Anvil, Jochen, die ist ja großartig.
Anvil ist ja eine ganz
verrückte, abgefahrene Sache.
Was ist Anvil? Ein Schmiede-Amboss
für... Ja, das ist quasi
JavaScript aus Python.
Die haben
einen Python-Compiler
für
JavaScript, der JavaScript erzeugt. Das heißt, du kannst
dein System komplett in Python schreiben
und hast dann aber trotzdem hinterher
eine JavaScript-Webseite.
Großartig. Großartige Idee.
Funktioniert auch.
Kann man jetzt schon
benutzen. Er hat auch eine Live-Demo gemacht, die dann sofort
live war. Auch
sehr großartig. Weiß nicht, ob das Ding noch live ist.
Müssen wir mal gucken.
Ja, aber es geht auch,
das ist dann schon nicht mehr Django.
Anvil ist, glaube ich, relativ wenig Django.
Ja, ja, ja. Genau.
Aber vielleicht ist das ja genau das
Indiz dafür, dass das aus dem lokalen
Maximum da raus... Ich glaube auch, es ist
einfach schwer, du kannst auch Django nicht mehr so leicht
verändern. Du kannst ja nicht einfach sagen, wir bauen
jetzt Django so um, dass es sowas wie Anvil ist.
Ja, das würde halt... Das ist einfach so viel Arbeit.
Das Johannes eben gesagt hat, dass wir Module
daraus machen. Ja, das wäre
möglicherweise ein Grund, das zu
tun. Wenn man sagt, also ich meine, es fängt ja schon bei
sowas an wie Django Admin, haben ja auch schon viele
Leute gesagt, aber es wäre doch auch cooler, wenn das irgendwie
so ein bisschen reaktiver wäre und wenn man da irgendwie
so ein paar modernere... Es geht halt nicht, weil
Django Admin Neuschreiben... Oder wenn man seine Anwendung da besser
integrieren könnte. Ja, aber
es wird halt auch da, wird dann immer gesagt, so ja, Django Admin
Neuschreiben, vergiss es einfach, das kriegst du ja nicht mehr hin.
Das ist nicht zu machen. Ja, oder
es ist halt nicht... Es ist halt das
lokale Maximum, ja. Du kannst ein Django Admin schon
Neuschreiben, aber der wird erstmal eine ganze Weile
lang sehr viel schlechter sein, als der Django hat,
mit dem du jetzt hast.
Und dann ist die Motivation
schon so ein bisschen so, ach ja,
dann nehme ich halt den Django ab.
Und das vielleicht, ja, vielleicht
ist das der richtige Weg, das zu modularisieren.
Ja,
ich meine, ich würde da sagen,
Flask, um da nochmal, weil da gab es
noch News zu.
Das ist ja der andere Ansatz,
das ist ja sozusagen,
alles ist modular und du bastelst
dir das halt selber zusammen. Und es gibt auch keine
Standardmodule, sondern du musst dir selber Standardmodule
suchen.
Da gab es jetzt eine neue Release,
Flask 2.0, und
ich hatte ja mal so irgendwie
Kess behauptet, ah, das wird nie
irgendwie, weil
ich hatte das noch so in Erinnerung,
dass da ja auch mal sehr, sehr
stark geachtet wurde auf Abwerbskompatibilität
und möglichst, also gerade,
na, wie heißt der noch?
Dings da, Armin,
der missfällt das ja total, dass
irgendwie der
der hat ja am liebsten Abwärtskompatibilität
bis, weiß ich nicht, eigentlich
bis ganz weit, bis Jahrzehnte zurück.
Was ich ja auch verstehen kann in gewisser Weise.
Ja, ja, hat auch Vorteile.
Aber auf der anderen Seite würde das eben bedeuten,
ja, sowas wie Async Await, das wird dann
halt nie gehen, weil das, oder
und Flask ist halt auch
direkt setzt halt, ist eines der ersten Frames, das
direkt auf WSGI aufsetzt, was halt
ein Problem ist, weil
naja, das ist halt nicht Async
und das kriegst du auch nicht dazu.
Und Django hat es da sogar ein bisschen einfacher,
weil Django ist nämlich älter als
WSGI und WSGI ist schon
irgendwie da so
dran gebastelt und jetzt kann man
halt auch noch was anderes ranbasteln.
Auf jeden Fall eine Stelle, an der man was ranbasteln kann,
die bei Flask so nicht da ist. Deswegen dachte ich so,
naja, also das Flask-Async-fähig
wird nicht passieren. Aber es ist
tatsächlich passiert, jetzt mit 2.0 geht
das und sie haben auch eine Menge
eben, sie haben halt die Abwärtskompetitivität
beendet, jedenfalls.
Aufgegeben.
Ja gut, okay, aber in einer Major-Release
kann man das auch machen.
Aber dann hätten sie es, geschickterweise
hätten sie es Flask 3 nennen müssen,
weil das ist doch das, wo in Python immer die
Kompetenzen zerbrechen.
Genau,
das braucht
jetzt mindestens Python 3.6 und
genau, man hat jetzt auch Async-Geschichten
da drin und SGI und
es gab da immer so ein Ding
dafür, Quad, das gibt es auch immer noch, das ist
ja, da hatte ich das übrigens
auch her, die Idee
aus einer Podcast-Episode mit
dem jetzigen Maintainer von
Flask,
dass man doch, weil der sagte so,
ja ey, wozu braucht man das denn?
Das ist doch irgendwie, in der Flask-Welt
machen wir das schon seit jeher mit
Eventlets und G-Event.
Ich so, ha, okay.
Und das geht?
Und das geht? Und dann habe ich es probiert und ja, es geht.
Tatsächlich, das kann man machen. Und das ist halt
möglicherweise auch tatsächlich eine einfachere Lösung für
dieses File-Surf-Problem
einfach einen Geo-Event-Worker
nimmt, der dann halt die Standard-Bibliothek
monkeypatcht und alle synchronen
I.O. Calls ersetzt durch
nicht blockierende und
das funktioniert dann einfach magisch.
Über monkeypatching ist halt so ein bisschen gefährlich,
aber wenn das nur für die Worker macht, die die
Files ausliefern, ist es vielleicht auch nicht so schlimm.
Ja, aber
und was man da auch machen kann,
ist, man kann das gleichzeitig machen. Man macht halt
Geo-Event irgendwie auf dem
Main-Thread und
packt halt, und das macht Django ja auch, und zwar
auch aus dem Grund, um G-Event und
Eventlets nicht zu brechen,
den ganzen, die lässt
die Event-Gloob in einem anderen Thread laufen.
Und dann alles, was I think Await macht, läuft dann halt
in einem anderen Thread und
trotzdem funktioniert diese ganze
Eventlet-G-Event-Geschichte weiterhin.
Also, interessant
wusste ich alles gar nicht, aber auf der anderen Seite
sagten die auch, ja, also tatsächlich, um
kompatibel zu sein zu moderneren
Bibliotheken und so, wo man Await-Syntax
verwenden
mustern, weil die nur noch das können.
Hm, ja, bleibt uns wohl auch nichts anderes
übrig, müssen wir das auch irgendwie können,
weil du kannst halt in einem synchronen Funktionsaufruf
nicht irgendwas erwähnen, das geht einfach nicht.
Ja, und deswegen ist es
auch in Flask jetzt drin und ja, das wird
also Flask immer noch weiterentwickelt,
voll gut. Ich weiß nicht
so recht, ich habe mit dieser ganzen
Welt nicht so wahnsinnig viel zu tun,
weil ich jetzt ehrlich gesagt auch keine Flask-Projekte
oder sowas habe oder Dinge, wo ich was
drin schreibe. Ich benutze dann immer,
Ich habe noch ein paar Sachen, die
Fast-API sind und das finde ich auch sehr nett.
Und ich glaube, das ist ja so ähnlich wie Flask quasi.
Also auch
in der Hinsicht, dass es halt nicht
dir vorgibt, was
also es ist halt nicht integriert, sondern
es bringt gar nichts mit, sondern du musst
alles dann halt selber
konfigurieren und zusammenstecken.
Ja, aber es ist halt
war halt nativ direkt Async und macht alles über
Type und Annotation und so.
Ja, insofern.
Aber ja, es ist schön, dass Flask
halt auch jetzt einen neuen Release hat.
Wenn wir schon bei den ganzen Webfilmen sind,
liebt Pyramid eigentlich noch?
Ja, da gab es ja auch,
weiß nicht, ist jetzt ein paar Monate her, glaube ich, aber da gab es auch
einen neuen Release.
Habe ich allerdings auch nichts mehr zu tun,
keine Ahnung, kann ich nicht mehr drüber erzählen.
Aber in unserem
Bekanntenkreis gibt es Leute, die das
ganz stark
in der
Pi-DDF-Konferenz.
Kommt immer wieder was auf.
Ja, genau.
Ja, ich finde, dann haben wir einen kleinen Überblick
über die Jungle-Kongen tatsächlich jetzt gegeben.
Guckt euch doch die ganzen Videos an,
wenn sie alle draußen sind. Das ist bestimmt noch mal
interessant.
Ja, mache ich auf jeden Fall.
Genau.
Wollen wir noch was vergessen? Habt ihr noch was dazu?
Wollen wir noch Pics machen?
Oh ja, können wir machen.
Johannes, was ist dein Pick dieses Mal?
Ich habe
dieses Mal keinen Pick mitgebracht.
Na gut. Doch, doch, ich habe keinen Pick.
DevDocs.
Ah, ja, achso.
Tja, die hatten wir leider schon in der letzten Episode.
Hattet ihr schon? Okay, gut.
Dann wiederhole ich das, dann bekräftige ich das.
Jeder sollte sich das sofort auf seinen Rechner runterladen
und für alles benutzen.
Ich fand es ja sehr schön. Ich habe das jetzt kürzlich
gefunden und habe dann natürlich direkt alle
Dokumentationen runtergeladen, die es runtergeladen hat.
Vielleicht, weil du unseren Podcast gehört hast?
Natürlich, weil ich das nachgeholt
habe, habe ich es nachgeholt quasi.
Was mich sehr
belustigt hat, war, ich habe diese Dokumentation
runtergeladen in den Offline-Modus und die
Django-Dokumentation sind, glaube ich,
6 MB und die Python-Dokumentation
sind etwas über 9 MB und die
Dokumentation für die DOM sind 64
MB.
Also
6,5 Pythons
muss man
komplett kennen, um
die DOM benutzen zu dürfen.
Fand ich
erschreckend, schrägstrich belustigend.
Ja, damit ihr noch mal wisst, was das ist,
man kann sich halt tatsächlich auf einer einzigen
Seite die Dokumentation von verschiedensten
Frameworks und Sprachen irgendwie
auf seine Favorites legen und hat dann direkt einen Zugriff
auf das Buch.
Ja, und auch offline.
Jochen, was ist deine
Pick?
Das ist eine sehr frohe Frage.
Ich kann vielleicht auch, was ich tatsächlich
sehr schick fand, habe ich jetzt,
das meine ich auch,
EIO SQL
ist so eine ganz eigene Art,
wie man jetzt nochmal, also
ich dachte dran, musste dran denken,
ich weiß nicht mehr, wie ich drauf gekommen bin,
als ich den Talk zu RAW, SQL
und Django gehört hatte
und dachte so, ja, also man kann
halt auch
sich so als
alternatives Konzept zu dem klassischen ORMs,
die man so hat, einfach alles
über Statements definieren
und dann diese Statements halt so ein bisschen
parametrisierbar machen und das ist halt,
das ist auch alles Async und so und
das ist auch eine sehr nette
Geschichte, kann man sich mal angucken.
Also direkt SGL-Statements aus.
Ja, ganz, ganz anderer Ansatz als der
OEM-Ansatz, den man so kennt, aber auch irgendwie
interessant.
Und, ah, eine Geschichte,
das fand ich sehr verwunderlich, ich dachte jetzt
eigentlich, ich fange jetzt mal mit so einem Stream an, ich habe ja auch nirgendwo
gesagt, dass ich das tue oder so, außer euch
jetzt.
In dem Twitch-Stream waren eigentlich
relativ sofort irgendwie Leute drin und
ja, da muss ich mich auch erstmal dran gewöhnen.
Und
da hat jemand gesagt, also als ich
mit Git die ganze Zeit so rumgemurkst habe
auf der Kommandozeile, nimm doch einfach Tick.
So, das gebe ich jetzt einfach mal so weiter.
Ich habe es noch nicht benutzt, ich weiß gar nicht, ob das gut ist, aber das ist wohl
ein Endcursus
Client für Git, der vielleicht
ein bisschen besser ist.
Interessant.
Muss man sich mal angucken. Ja, ich habe auch noch
einen kleinen Pick, ich würde diesmal eine Business-Anwendung
nehmen, und zwar Lifetimes.
Das gibt es auf PyPy und
wenn man da quasi Bestelldaten von
Kunden reinpiped, dann
bekommt man quasi die Absprungrate, die
Churnrate ausgerechnet.
Und das ist tatsächlich gar nicht so schlecht, wenn man
so Sales machen möchte oder so.
Ja, hab ich so entdeckt und fand ich gut.
Funktioniert echt gut für gute
Businesses. Kann man wahrscheinlich auch verkaufen,
also an Endkunden oder so, die wollen das alle haben.
Die Library, dass du einfach
nur die Library verkaufst, oder? Ja, du musst
natürlich schon... Rechnen euch die Churnrate.
Durch die Daten der Kundenpipen, aber ja.
Ja klar, das als Service anzubieten.
Das ist eine coole Idee.
Ja, vielen Dank,
dass ihr wieder eingeschaltet habt, dass ihr zugehört habt.
Bleibt uns gewogen. Hört uns nachts, morgens, mittags,
abends, am Wochenende, unter der Woche
beim Schwimmen gehen.
Ja, schönen Tag,
schönen Zeit.
Bis dann. Tschüss.
Ja, spät wieder.
Tschüss. Ja, diesmal lassen wir uns nicht so viel Zeit.
Ja. Bis dann. Tschüss.