Transcript: PP02 - Django

Ja, hallo liebe Hörerinnen und Hörer, willkommen beim Python-Podcast in der heute zweiten Episode.

Wir haben euch da ein ganz besonderes Thema für euch mitgebracht, und zwar Django.

Für das zweite Mal natürlich ist es auch schon ein steiles Thema, aber ich glaube, das kriegen wir gemeinsam hin.

Wir versuchen auch eine Einführung dazu zu machen, fangen heute ein bisschen an, wieder mit den Basics,

und dann gehen wir ein bisschen in die Tiefe des Themas.

Wir sind wieder im wunderschönen Wintergarten hier von Jochen, ich bin der Dominik,

und diesmal habe ich nicht nur den Jochen dabei, sondern auch den Johannes.

Danke auch nochmal, hallo ihr zwei.

Ja, genau, hier ist auch Jochen, hallo von mir.

Und genau, zum Django-Thema haben wir uns direkt schon mal einen ersten Expertengast eingeladen,

und wir hoffen, dass der da irgendwie mehr weiß als wir und uns da viele interessante Geschichten erzählen kann.

Und das ist Johannes, und genau, das kannst du dir vielleicht mal vorstellen.

Ja, hallo, ich bin Johannes.

Und nach der Ankündigung kann ich eigentlich gar nicht mehr so richtig viel sagen.

Jetzt sind die Anforderungen gestellt, und mal schauen, ob ich die erfüllen kann.

Also du arbeitest auch mit Django?

Ich arbeite auch mit Django, genau.

Ich arbeite mit Jochen viel zusammen, der ja auch mit Django sehr viel macht.

Und wir haben uns auch darüber kennengelernt, im Chaos Computer Club in Düsseldorf in der Python-Ecke.

Und haben dann festgestellt, dass wir beide Django machen.

Und ja, arbeiten eigentlich seither zusammen.

Gut, beim Python-Foodern, donnerstags.

Genau, jeden Donnerstagabend ab 18 Uhr.

Ja, also die Veranstaltungen kommen erst am Ende, aber wir versuchen das ab und zu nochmal ein bisschen einzuschreuen.

Nein, super.

Ja, wir machen heute Django, deswegen fangen wir vielleicht nochmal ganz am Anfang an.

Johannes kann, glaube ich, sogar etwas zur Geschichte von Django erzählen.

Er ist nämlich genauso ein alter Hase wie der Jochen.

Wäre doch super, wenn du nochmal kurz erklären könntest, was das ist, wo kommt das denn her, was macht man damit überhaupt.

Und also Django hört sich jetzt erstmal an.

Warte, ist das ein Tanz?

Ja, es ist benannt nach einem Jazz-Gitarristen, Django Reinhardt.

Die beiden Entwickler, die sich das ausgedacht haben, waren wohl Fans von diesem Gitarristen.

Es hat sonst auch keinerlei Verbindung mehr dazu, nur der Name stammt daher.

Django ist ein Framework, um Web-Anwendungen mit Python herstellen zu können.

Da gibt es mehrere solcher Frameworks, aber Django ist da sicherlich das Größte und sicherlich auch das Ausgereifteste.

Das gibt es jetzt schon seit - jetzt müsste man rechnen können - knapp 15 Jahren?

Ja, ich glaube, 2005 ist es rausgekommen oder 2004, ich weiß nicht, ich glaube, kurz nach "Ruby on Rails".

Und ich denke, das war auch so ein bisschen vielleicht das Vorbild für Django.

Ja, ich weiß gar nicht, ob die sich gegenseitig als Vorbild genommen haben, weil die sind ja schon so ein bisschen unterschiedlich in ihren Ansätzen.

Ich habe das damals kennengelernt von einer Veranstaltung wie "Snakes and Rubies", sehr zu empfehlen auch.

Übrigens gibt es auf YouTube immer noch das Video, inzwischen ungeheuer alt, wo sich eben da die beiden Hauptentwickler getroffen haben.

Der Jack of Kaplan Moss war das, glaube ich, der da war und der von "Ruby on Rails" heißt David Hanmeier-Hansen.

Und die beiden haben so im Wesentlichen ihre beiden Ansätze vorgestellt und haben eben "Snakes and Rubies" gezeigt.

Und der eine, der Kaplan Moss, hat eben gezeigt, wie man Probleme mit Django löst.

Den Querschnitt, wir haben eine Möglichkeit, URLs zu definieren und dann eine Funktionalität dazu zu definieren und dann die Templates dazu anzuzeigen und Sachen aus der Datenbank zu holen.

Und dann hat der David Hanmeier-Hansen mehr oder weniger das Gleiche gemacht, aber auf eine ganz andere Art und Weise, eben auf die "Ruby on Rails"-Art und Weise.

Wodurch unterscheidet sich die "Ruby on Rails"-Art und Weise von dem, was wir jetzt suchen?

Ja, zuerst mal natürlich, dass es eine andere Programmiersprache ist.

Ja.

Aber "Ruby on Rails" geht wesentlich mehr über...

Konventionen.

Bei Django wird sehr viel explizit gemacht, also ein paar Beispiele ist, wie eben URLs funktionieren.

In Django definierst du eine URL, indem du einen regulären Ausdruck hinschreibst.

Und wenn der reguläre Ausdruck eben dem entspricht, was der Benutzer in seinem Browser eingibt, dann wird die entsprechende Funktion dazu ausgeführt.

In "Ruby on Rails" ist das anders.

In "Ruby on Rails" ist das durch eine Konvention gemacht.

Du hast einen Controller, der einen bestimmten Namen hat und über diesen Namen wird automatisch die URL bestimmt, über die du diesen

Controller ansprechen kannst.

Das heißt, du hast auf der einen Seite wesentlich stärkere Konventionen, du hast damit die Möglichkeit, ein "Ruby on Rails"-Projekt,

sag ich mal, schneller zu verstehen, weil die alle die gleiche Struktur haben.

Andererseits musst du diese Sachen eben wissen, du musst die Konventionen wissen.

Und das ist für mich so ein bisschen der große Unterschied am Anfang gewesen.

Ich mag es gerne, wenn Sachen explizit dastehen, wenn die Programme das tun, was ich hingeschrieben habe und nicht so ein bisschen magisch hintenrum

das tun, was halt eingerichtet ist, weil das jemand wusste.

Und das ist gleichzeitig eine Stärke und eine Schwäche, weil man eben dadurch in "Ruby on Rails" wesentlich schneller Ergebnisse sieht.

Ich muss nur diesen Controller schreiben und ich muss ihm nur eben eine bestimmte Datei an die richtige Stelle hinlegen und dann wird das automatisch zu einer

kompletten Webseite.

In Django muss ich den ganzen Weg gehen.

Ich muss die URL definieren, ich muss die Funktionalität definieren, ich muss die Datenbankmodelle definieren, ich muss die in die

Datenbank reintun, ich muss die aus der Datenbank wieder rausholen und dann muss ich sie in ein Template reintun, was ich selbst definiert habe.

Du hast gerade nochmal von Controllern geredet.

Vielleicht weiß jetzt noch nicht jeder Hörer, was das genau ist.

Wollt ihr das nochmal kurz erklären?

Ich weiß nicht, Jochen hat es einmal mir schon ganz schön erklärt, worum es dabei geht.

Ja, also das wäre dann halt auch so eine Gemeinsamkeit zwischen "Ruby on Rails" und Django.

Das sind beides so Model-View-Controller-Frameworks, also die diesen Ansatz halt halbwegs sauber irgendwie umsetzen.

Das heißt, es gibt halt Modelle, in denen

irgendwie definiert wird, wie die Daten aussehen, die man jetzt in der Applikation hält.

Also wie der State der Applikation quasi abgelegt ist, sich verhalten soll.

Meistens hat man eine relationale Datenbank irgendwie im Hintergrund und dann muss halt aus den Modellen wird dann halt ein Schema generiert.

Dann werden die Daten halt da irgendwie reingespeichert.

Und dann hat man sogenannte Controller, die quasi die Daten, die in den Modellen sind, mit den Views,

die halt dafür zuständig sind, wie das hinterher aussehen soll, für ein Benutzer-Interface verbinden sollen.

Wobei Benutzer-Interface ganz unterschiedliche Sachen sein können.

Also ein Beispiel ist, man macht irgendwie ein Weltraum-Kampfspiel und dann gibt es halt vielleicht irgendwie ein grafisches Interface,

wo man irgendwie die Raumschiffe rumfliegen sieht und so.

Aber man kann sich halt auch vorstellen, dass ein anderes Interface nur textbasiert ist,

weil wo sich dann Leute quasi per Telnet irgendwie einloggen oder so und das muss dann natürlich unterschiedlich

aussehen, je nachdem, was man für ein Interface hat.

Oder wenn man jetzt ein Touch-Interface hat, ist es nochmal anders.

Und dafür diese Unterschiede abzubilden, ist halt der View zuständig und der Controller.

Die sind halt dafür da, sozusagen die Views mit den Modellen irgendwie zu verbinden, also die Daten irgendwie aus den Modellen zu holen,

die dann in der Form den Views zu geben, die sie deshalb brauchen.

Und ja, das Ganze nennt man irgendwie Model-View-Controller.

Also Modell ist das, was in der Datenbank angelegt ist, wie dann das...

Ja, aber auch die Objekte quasi, die hinterher in der Applikation sich um die Datenhaltung kümmern, sind auch sozusagen die Modelle,

ja.

Okay.

Also Datenbank ist halt eigentlich nochmal ein Problem.

Also die klar ist, man benutzt die Verwaltung von dieser Datenbank auch.

Ja, ja, genau, genau.

Und was ein bisschen verwirrend ist, ist halt, dass in den Django, die die Views Templates heißen und die Controller-Views,

das, weiß nicht, ein bisschen...

Hier sind wir alle ein bisschen verwirrt und durcheinander, okay.

Ja, da stolpern Anfänger oft drüber, dass die Bezeichnungen anders sind und eben ausgerechnet View und View unterschiedliche Dinge bedeuten.

Gemein, da muss doch jemand mal so...

Da muss jemand mal so ein Request stellen und sagen, hey, ändert das mal, oder?

Ja, aber nach über zehn Jahren ist das halt ein bisschen schwer zu ändern.

Ja, das ist halt nicht...

Da haben sich ja die anderen Leute auch dran gewöhnt, wie das dann heißt, ja, verstehe, verstehe.

Ja.

Ja, also wofür nutzt man denn Django, wenn ihr jetzt gesagt habt, was da schon man machen kann?

Mhm.

Ja, im Prinzip kann man jede Web-Anwendung damit herstellen.

Und die Breite ist da, also es gibt quasi keine Begrenzung.

Das ist die erste Anwendung, die sicherlich...

Was sicherlich jeder machen muss, ist ein Blog.

Und jeder Django-Entwickler, der mehr als ein halbes Jahr daran gearbeitet hat, hat auch schon mal einen Blog damit gemacht.

Ja.

Dann gibt es so die ganz typischen Sachen, ein Wiki, Programmieren einfach mal auch zur Übung.

Ich mache regelmäßig Django-Kurse und da programmieren wir dann Shops nach oder eBay nachprogrammiert oder Twitter nachprogrammiert, einfach um zu sehen, wie solche Funktionalitäten in Web-Anwendungen umgesetzt werden.

Ja, also bei einem einwöchigen Kurs ist es absolut kein Problem, eine Basisfunktion von jeder dieser Webseiten hinzukriegen.

Klar, die sehen nicht so schön aus und die haben auch nicht so viele Funktionen wie die tatsächlichen Vorbilder, aber die Grundvorgangsqualität ist eben sehr schnell damit umzusetzen.

Auf was konzentrierst du dich dann besonders in diesem Kurs, also auf das Model, das View, das Controller-Ding?

Ne, die müssen alle drei zusammenarbeiten, weil du mit jedem dieser Teile allein kannst du nicht, hast du keine komplette Anwendung.

Ich habe keine komplette Anwendung, wenn die drei zusammenarbeiten.

Das heißt, man muss so zwischen diesen Bereichen hin und her springen und da gibt es auch verschiedene Möglichkeiten, damit umzugehen, die sich auch, gerade wenn man mit anderen Leuten darüber spricht, zeigen, dass da jeder unterschiedlich damit umgeht.

Aber im Endeffekt geht es darum, diese drei Bereiche zu verheiraten und diese drei Bereiche so zusammenzubringen, dass eine Anwendung daraus wird.

Das heißt, ich brauche irgendwoher Daten, die ich handhaben kann.

Und diese Daten sind eben in den Modellen definiert.

Ich brauche irgendwelche Sachen, die ich anzeigen kann, weil im Endeffekt eine Webseite daraus werden soll.

Das heißt, ich brauche so ein Template oder in der klassischen Sprache, ich brauche einen View.

Und ich brauche irgendwas, was eine Funktionalität darstellt, weil sonst macht meine Web-Anwendung nichts.

Und das ist hier in Django eben der Controller bzw. die View-Funktion.

Nur wenn ich diese drei Teile zusammen habe und wenn die drei Teile so ineinander greifen, dass sie zusammen funktionieren,

daraus eine Web-Anwendung.

Das heißt, der Trick an der ganzen Sache oder der Trick an Django ist eigentlich nicht, dass sie diese drei Dinge gefunden haben

oder diese drei Bereiche geschrieben haben, sondern dass die so integriert sind, dass die nahtlos ineinander greifen.

Klingt praktisch.

Ja, ist es auch.

Eine Stelle, an der man das ganz schnell sieht, ist der Django-Admin.

Das ist eines der am meisten gelobten Module in Django.

Also Django-Admin ist das Backend.

Das ist sozusagen ein genialer Zaubertrick, weil der Django-Admin, das ist einfach ein Modul in Django.

Und ich kann das reinladen, das hat eine URL wie alles andere auch.

Aber was der machen kann, ist, der kann die Modelle, die ich geschrieben habe, inspizieren und mir die dann eben in einer schönen Darstellung zeigen.

Das heißt, ich habe automatisch eine Backend-Funktionalität drin, ich habe automatisch eine Verwaltungsfunktion drin, die aber meine Modellierung nimmt.

Das heißt, die sich auf meine Modellklassen bezieht und die mir das Schreiben von so einer Backend-Funktionalität im Wesentlichen wegnimmt.

Und das ist eine sehr schöne Sache, wenn man eben so eine Anwendung zum ersten Mal schreibt und sagt, okay, ich habe mich jetzt an WordPress orientiert, ich möchte einen Blog machen.

Jeder möchte einen Blog machen am Anfang.

Dann gehört dazu eben auch so ein Interface, wo ich die Blogposts bearbeiten kann.

Und in der ersten Version kann man das sicherlich...

Man kann das sicherlich im Django-Admin einfach drin lassen, weil es da die Möglichkeit gibt, Seiten hinzuzufügen und Seiten zu bearbeiten und Seiten zu löschen und vielleicht Seiten, keine Ahnung, wenn man das modelliert hat, freizugeben oder irgendwo hinzuverschieben oder sonst was zu machen.

Diese ganzen Basisfunktionalitäten, die man immer braucht, die sind im Django-Admin schon drin.

Das heißt oft CRUD, Create, Read, Update, Delete.

Das sind die vier Funktionen, die man immer mit seinem Datenbank-Ding tun muss und die sind eben schon im Django-Admin drin.

Das ist einfach eine sehr praktische Sache, weil diese drei Teile, Model, View und Controller, so gut integriert sind, dass man quasi aus Django heraus die zusätzlichen Dinge da mit reinnehmen kann.

Ist das bei Django ganz individuell oder einzigartig und machen das die anderen Frameworks, die es in Python oder so gibt, von Flask oder von Pyramid mal gehört, auch so?

Ja, gut, es gibt auch noch andere, die das auch so machen, aber ich würde sagen, die Bekannteren, die das halt komplett integrieren, sind eben Django.

Für Python oder halt eben Ruby und Rails für Ruby.

Und wenn man jetzt zum Beispiel Flask nimmt, dann ist das eher ein etwas anderer Ansatz.

Da ist es halt so, dass der Layer, also Flask selber enthält kaum Model-View-Controller-Funktionalität, wie man sonst so in Django hat.

Also es ist halt nicht alles integriert, sondern da kann man sich halt Dinge zusammenstecken, die man benutzen kann.

Zum Beispiel der Object-Relational-Mapper.

Also ORM genannt oft, ist halt in Flask meistens SQL-Alchemy.

Man kann aber auch irgendwas anderes nehmen.

Man kann, wie heißt dieses Dings, Pony oder so, was da irgendwie heute recht beliebt ist, nehmen oder so.

Man könnte auch den Django-ORM nehmen.

Man könnte auch den Django, genau.

OR was?

ORM Object-Relational-Mapper.

Das ist die Verbindung zwischen der SQL-Datenbank, die eben rohes SQL braucht, und der Python-Welt, wo wir ja mit Python-Klassen arbeiten.

Okay, jetzt habe ich das verstanden.

Ja, und genau, bei Flask ist halt der Vorteil, dass man sich da quasi die Dinge, die man vielleicht auch sonst verwendet, oder die man lieber mag, irgendwie benutzen kann.

Während bei Django kann man das theoretisch auch.

Mit manchen Dingen ist es einfacher als mit anderen.

Aber ich würde es jetzt nicht unbedingt gerade empfehlen.

Also den Django-ORM auszutauschen ist halt, ja kann sein, dass das geht, aber das will man wahrscheinlich eher nicht tun.

Wo man das macht, nimmt man dann vielleicht auch besser Flask oder so.

Und ja, das sind halt unterschiedliche Trade-offs.

Das hat halt gewisse Vorteile, wenn alles integriert ist.

Und es hat halt auch gewisse Nachteile.

Es ist halt ein bisschen weniger Flexibilität.

Es ist eine steilere Lernkurve am Anfang.

Aber weil einfach viel mehr Funktionalität da ist, mit der man irgendwie sich vertraut machen muss.

Aber wenn man da erstmal so durchgestiegen ist, dann ist es halt auch schneller, damit irgendwas zu machen.

Oder das halt auf neue Anforderungen anzupassen, als wenn man das jetzt irgendwie immer neu zusammenstöpseln muss.

Wie ist das denn zum Beispiel?

Wenn ihr jetzt so ein Modul benutzt, was es irgendwie schon gibt,

wie viel Arbeit wäre das denn jetzt, in so ein neues Framework zu integrieren?

Das kommt total auf das Modul an.

Diese Fragen kann man so eigentlich nicht beantworten.

Die Mentalität, glaube ich, zwischen diesen Frameworks ist auch so ein bisschen unterschiedlich.

Flask ist so ein bisschen, du kannst alles benutzen, was du willst.

Du musst dann halt selber dafür sorgen, dass die Teile zusammenpassen.

Und Django ist mehr so ein bisschen, hier wir haben den Bowser,

der hat es gemacht und du kannst gerne darauf aufbauen.

Aber die müssen so funktionieren, wie wir das vorgegeben haben.

Das heißt eben, wenn ich irgendein Modul habe oder eine Bibliothek, die nicht integriert ist,

dann bin ich in Flask sicherlich schneller damit unterwegs,

weil ich dann eben sowieso für diese Anbindung sorgen muss.

In Django ist es dann eben oft so, dass es schon eine Django-Variante gibt davon,

die mir eben genau diese Integration schon gibt.

Und dann ist es natürlich leichter, die Django-Variante zu verwenden.

Heißt halt aber, dass ich darauf angewiesen bin,

dass schon jemand die Arbeit gemacht hat und auch fortlaufend tut,

weil die Versionen natürlich ständig aktualisiert werden.

Und es hat alles so seine Vor- und Nachteile.

Wie würdet ihr denn einsteigen, wenn ihr jetzt irgendwie jemanden habt,

der das noch nie gemacht hat?

Möchtet ihr seine erste Website, einen Blog einstellen?

Das würdet ihr ihm empfehlen?

Einfach das Paket installieren und Tutorial lesen?

Oder gibt es da schon eine Best Practice, wo ihr am besten...

Ja, also ich würde, das habe ich bisher dann auch immer so gemacht.

Wenn ich das gefragt worden bin,

das Two Scoops auf Django-Buch zu empfehlen.

Also das ist jetzt halt momentan nicht mehr so richtig super aktuell.

Ich glaube, die letzte Auflage ist für Django 1.11.

Und wir sind jetzt aber auch eigentlich schon bei 2.1.

Da kommt dann wahrscheinlich für die nächste stabile

oder länger supportete Release von Django

wahrscheinlich auch wieder eine neue Version.

Aber da wird eigentlich mal so grob beschrieben,

wie man Dinge tut mit Django und so.

Also ich fand das...

Ich habe damals auch quasi einen Einstieg in Django

über dieses Buch gefunden.

Das war irgendwann 2013 oder so,

weil ich irgendwie in einem Projekt plötzlich

mit einem Django-Backend konfrontiert war.

Und dann, ja, mir auch gesagt wurde,

dann liest doch mal einfach dieses Buch

und dann macht alles Sinn plötzlich.

Und so ein bisschen war das schon so.

Also das war sehr, sehr hilfreich.

Ja, man kann aber auch mit der Dokumentation,

die sehr gut ist, anfangen.

Oder, ich weiß nicht,

vielleicht mit einem von Johannes Grosen.

Oder Facebook.

Ja.

Nee, ich mache das tatsächlich nicht so.

Ich mag dieses Two Scoops of Django-Buch

nicht ungeheuer gerne,

weil das sehr viele eigene Meinungen schon mitbringt.

Und weil man die erst bemerkt,

wenn man sich so ein bisschen mehr damit auskennt.

Ich meine, das ist nicht schlecht, ja.

Und die Leute, die das machen, sind auch Experten.

Und wir benutzen auch sehr viel davon.

Wir werden vielleicht noch über Cookie Cutter sprechen.

Aber ich finde, es hat schon zu viel Flavor.

Es ist schon zu weit von Vanilla Django weg.

Das sind ja noch mehr Freiheiten,

die du selber gerne kreativ ausleben würdest,

wenn du genau verstanden hättest, wie es funktioniert.

Genau.

Und das bedeutet auch,

dass man eben auf diese Wahl festgelegt ist,

die die Leute von Two Scoops of Django schon getroffen haben für uns.

Weil die eben, wie gesagt, ihre Meinungen haben.

Und weil die sagen,

okay, du solltest eigentlich immer diese bestimmten Systeme verwenden

und eben nicht diese anderen.

Ja, genau.

Hast du das schon getan, so ein Beispiel?

Ja, zum Beispiel, wenn die ihre Docker-Container bereitstellen.

Es gibt oft Situationen, wo man eben keine Docker-Container haben möchte.

Das ist halt aber bei denen einfach so.

Die haben alles dockerisiert.

Ist einfach so eine Sache, oder?

Die benutzen Django-Crispy-Forms,

wo ich am Anfang sehr damit zu kämpfen hatte,

weil es gar nicht dem entspricht, wie ich das machen will.

Müssen wir vielleicht gleich nochmal kurz erzählen,

was ein Docker-Container ist und was eine Crispy-Form ist?

Das sind einfach nur so zwei Beispiele,

wo Two Scoops of Django schon was ausgewählt hat,

was man eventuell anders machen würde.

Es ist unwichtig, was das jetzt genau bedeutet

oder was das jetzt genau ist.

Ich fange üblicherweise mit dem Tutorial an auf der Webseite,

weil es zum einen relativ gut geschrieben ist.

Die Django-Dokumentation ist erstklassig,

die ist anwandfrei, die ist super.

Kann ich jedem nur empfehlen.

Auch wenn man nur die Django-Dokumentation liest

und das alles mehrmals angeschaut hat,

dann ist man Experte in Django-Dokumentation.

Und das Tutorial ist einfach ein schneller Einstieg

in was muss ich tun, um eine Funktionalität zu kriegen.

Aber eigentlich würde ich noch einen Schritt vorher anfangen.

Wenn sich jemand da einlesen möchte

oder wenn jemand anfangen möchte, mit Django zu programmieren,

ist meine Empfehlung, immer erstmal einen Schritt zurückzugehen

und zu überlegen, genau was man eigentlich erreichen möchte.

Weil es oft schwierig ist, das gleichzeitig zu machen,

gleichzeitig zu lernen, wie man etwas erreicht

und herauszufinden, was man eigentlich erreichen möchte.

Das heißt, du würdest dir ein Projekt ausdenken,

was derjenige dann umsetzen möchte,

ob es jetzt Freizeit ist oder irgendwie nebenbei

oder schon was Professionelles

und dann direkt an diesem Projekt konkret

sich die Lösungen aus Django dann zu erarbeiten.

Genau, und vielleicht auch einfach mal konkret zu sagen,

was muss ich haben an Funktionalität,

um mein Ziel erreicht zu haben.

Und machst du das dann richtig mit Stift und Papier

oder aus einem Whiteboard

oder malst du da eine Kreidetafel voll?

Je nachdem, wo ich gerade bin

und was gerade für Werkzeuge da sind.

Wenn ich nur einen Texteditor da habe,

dann schreibe ich mir halt ein paar Punkte im Texteditor ein.

Wenn ich die Wachsmalstifte von meinem Kleidung dabei habe,

dann male ich mir was auf die Hand.

Nee, es ist einfach nur wichtig,

ein Bild davon zu haben, was man erreichen möchte.

Zu wissen, wo möchte ich hinkommen.

Soll das ein Blog sein,

was YouTube-Videos anzeigt?

Soll das ein Podcast-Blog sein

oder soll das ein Blog sein,

wo ich nur, keine Ahnung, meine Texte reinschreibe?

Müssen da Bilder rein?

Müssen da andere Dateitypen rein?

Will ich Sharing-Buttons haben?

Lauter so Sachen,

die jeder für sich entscheiden muss,

die jeder für dieses Projekt entscheiden muss

und die sicherlich in jedem Projekt anders sein werden,

die aber eben dazu führen,

dass man während man daran arbeitet,

nicht mehr so viel drüber nachdenken muss.

Und das ist für mich eine ganz wichtige Sache,

dass ich eben weiß, wo ich hin möchte.

Also, das kann sich zwischendurch ja ruhig ändern.

Ja, das kann ja ruhig,

man muss ja seinen Weg auch anpassen können.

Und wenn man sich eben herausstellt,

dass man sich zu viel vorgenommen hat

oder dass das, was man sich vorgenommen hat,

nicht erreichbar ist oder dass es zu schwer ist,

dann muss man das vielleicht anders machen.

Aber man sollte trotzdem immer wissen,

wo man hin möchte.

Weil wenn man, wenn man dann anfängt,

tatsächlich diese Umsetzung zu machen,

ist man so sehr damit beschäftigt,

die Dinge zu lernen, die man wissen muss.

Dass es schwer ist, sich Gedanken darüber zu machen,

ob das überhaupt sinnvoll ist.

Ist es denn sinnvoll, so vom Scratch total anzufangen,

alles selbst zu bauen?

Oder nimmt man dann direkt so etwas

wie ein Template aus einem Cookie-Cutter?

Vielleicht, Jörg, kannst du nochmal kurz erzählen,

was das überhaupt ist?

Ja, also, genau.

Also, ein Problem bei Django ist halt,

da ist schon relativ viel Funktionalität enthält

und viele Teile.

Und man möglicherweise für ein System,

was dann hinterher irgendwas tun soll,

wie ein Block implementieren oder so,

noch viel mehr Kram braucht.

Da braucht man halt,

möglicherweise noch irgendeine Anbindung an ein Cache-Backend,

Redis oder sowas, mein Cache-Di.

Braucht vielleicht irgendwie eine Volltext-Suchmaschine,

die man dann auch noch drin hat.

Man hat vielleicht irgendwelche Background-Tasks,

die laufen müssen und so weiter und so weiter.

Da gibt es noch eine ganze Menge Dinge,

die man halt irgendwie einstellen muss,

wo man Entscheidungen treffen muss.

Und das ist doch relativ überwältigend,

denke ich mal, für jemanden,

der eigentlich nur mal einen Block schreiben wollte

und mal schnell irgendwie eine Django-App,

hochziehen wollte.

Und da gibt es dann halt so ein Tool,

nennt sich Cookie Cutter.

Das ist auch von den Autoren von Two Scoops of Django

oder beziehungsweise von einer der beiden Autoren.

Und das legt dann halt so ein Projekt quasi an.

Da werden einem am Anfang im Grunde

genau so ein paar dieser Fragen gestellt.

So, möchtest du Docker oder lieber nicht?

Oder brauchst du eigentlich Hintergrund-Tasks wirklich?

Und wenn man das angegeben hat,

dann, wenn man das angegeben hat,

dann wird quasi aus den,

wenn halt die Template-Variablen,

die im Projekt-Template drin sind,

ersetzt durch konkrete Werte.

Also man gibt dem Projekt halt einen Namen und so.

Der wird dann relativ oft eingetragen

und dann wird halt so ein Projekt erstellt.

Und das läuft dann halt auch direkt von Anfang an.

Und damit hat man dann ja quasi schon mal

einen großen Schritt geschafft,

weil bis dahin zu kommen,

möglicherweise auf anderem Weg

relativ lange dauern könnte.

Auf der anderen Seite hat man dann natürlich das Problem,

dass man nicht genau weiß,

was passiert ist.

Und man hat jetzt auch viele

sozusagen Einstellungen schon vorgenommen sind,

von denen man jetzt gar nicht genau weiß,

ob man die wirklich so haben wollte oder nicht.

Und ja,

die man auch nur noch schwer ändern kann.

Und man versteht nicht so genau,

was da passiert.

Und das ist natürlich in gewisser Weise so ein Nachteil.

Aber es ist, denke ich,

schon halt irgendwie eine Möglichkeit,

relativ schnell zu einem funktionierenden System zu kommen.

Und ja,

darauf aufbauen kann man dann ja weitermachen.

Aber ja,

es kann einem eine Menge Arbeit ersparen.

Ich mache das meistens so,

wenn ich neue Projekte irgendwie aufmache,

dass ich halt dann irgendwie

das Django-Cookie-Cutter-Template benutze.

Aber ja,

das trifft dann natürlich schon eine ganze Menge Entscheidungen,

die man vielleicht auch anders treffen können wollte.

Klingt aber,

als könnte man es gut gebrauchen für,

sagen wir mal,

Projekte, bei denen man schon relativ genau weiß,

was man will.

Ja.

Naja, also ich meine,

ich habe,

das ist halt dann,

die Frage,

ob man sozusagen

das, was man tun möchte,

den eigenen Bedürfnissen anpasst

oder die eigenen Bedürfnisse halt so,

so ähnlich wie eine SAP-Einführung.

Also quasi,

wenn man sich dafür entscheidet,

das zu verwenden,

dann muss man halt die eigenen Prozesse so umstellen,

dass sie zu SAP passen.

Und dann geht das halbwegs.

Und bei Cookie-Cutter ist es halt auch so,

man muss dann die Dinge so machen,

wie dieses Template das halt irgendwie quasi

vorgibt.

Und wenn man das anders machen will,

hat man,

hat man Schwierigkeiten

oder dann ist es halt nicht mehr so hilfreich,

weil da muss man wieder eine ganze Menge von handen ändern,

was man,

was man ja eigentlich vermeiden wollte,

indem man Cookie-Cutter verwendet.

Daher ist es halt so eine,

also wenn man sich quasi damit abfindet,

dass alles so ist,

wie das in dem Template halt vorgesehen ist,

dann ist es eigentlich ganz nett.

Also dann,

wenn man das nicht so,

nicht so toll findet,

dann hilft es einem halt nicht.

Dann muss man vielleicht ein eigenes Template machen oder so.

Viele Sachen,

die in dem Cookie-Cutter-Template drin sind,

gehen für mich so ein bisschen in Richtung Produktivbetrieb.

Ja.

Die nehmen einem viel Arbeit weg,

wenn man dann Produktivbetrieb hat.

Die haben Sachen drin für Content Delivery,

für Networks

und die haben Sachen drin für Docker

und die haben Sachen drin für Cached

oder für sonst irgendwelche Sachen.

Ich glaube,

wenn man zum ersten Mal so ein Projekt macht,

ist es einfacher,

from scratch einzufangen,

weil man viele von diesen Sachen dann einfach nicht braucht.

Das Blog,

was man da als erstes Mal entwickelt,

wird sicherlich nicht gleich 100.000 Hits pro Minute haben.

Woher willst du das denn wissen?

Also meine Blogs haben nie so viele gehabt.

Vielleicht habt ihr mehr Erfolg als ich.

Ich wünsche es euch.

Aber es ist sicherlich nicht die erste Ausrichtung.

Es wird sicherlich nicht das erste Problem sein,

dafür zu sorgen,

dass das die ganze Welt gleichzeitig lesen kann,

sondern das erste Problem wird sicherlich sein,

dafür zu sorgen,

dass es irgendjemand lesen kann.

Und das überhaupt läuft vielleicht.

dass man überhaupt einen Block hat

und ich glaube dann ist es einfacher mit

dem puren

mit dem Basis Django

umzugehen

Habt ihr ein Lieblingsmodul, ein Lieblingstemplate?

Also wenn ihr das schon einsetzt im Produktivbetrieb

oder

Das ist eine schwere Frage, weil da

oft sehr viele Sachen

zusammenkommen, weil man oft

sehr sehr viele

Bibliotheken reinlädt, die

alle nur einen kleinen Teil machen

Das ist so, wenn ich dich frage, welches

Lego-Teil ist denn dein Lieblings-Lego-Teil?

Ritterburg

Ja, aber das ist ja kein einzelnes Teil

Das ist ja gleich was sehr Großes zusammengebaut

Da sind viele kleine Steine dabei, glaube ich

Genau, und die einzelnen Steine an sich sind alle

nicht super interessant, aber wenn man sie dann

sowas zusammengebaut hat, dann

ist das, was man gebaut hat, super interessant

Okay, aber gut

Du weißt ja dann schon, welche Steine du dann brauchst

damit du dann irgendwie sowas gießen kannst

Ja, klar

Also das heißt, man hat sich schon so ein Workflow, an dem man sich dann gewohnt

und der ist dann auch irgendwie

Okay, individuell

Ja, aber auch da, also ich

jedes Mal, wenn ich

mit Leuten zusammenarbeite, dann

bin ich wieder überrascht davon, wie

unterschiedlich man die Sachen machen kann

Nicht schlechter

oder besser bei irgendjemandem,

aber einfach so unterschiedlich. Auf viele

Sachen, die der Jochen macht, komme ich einfach gar nicht

und das wird sicherlich umgekehrt sein

Genau das fände ich jetzt total interessant, also so Sachen

von euch noch zu hören, wo

sonst niemand auf den Punkt kommt, wo er sagt, hey,

mach mal drüber nach, das wäre ein toller Tipp, mach das doch mal

diesen Weg oder

Ja, also wenn ich da

quasi eine

App nennen sollte, wäre

das wahrscheinlich Django ImageKit

tatsächlich, weil

Django ImageKit?

Ich habe

da mal so einen Blog in Django

geschrieben und

bin relativ bald auf das Problem

gestoßen, dass man, wenn man jetzt so

ja, wir haben 2018

will man schon so irgendwie responsivee

Images haben und dass das halt auch auf dem Handy

irgendwie einigermaßen aussieht, aber man

möchte jetzt auch nicht alle Bilder in riesig groß

ausliefern

wenn man

ja eben auch gerade auf dem Handy

und so

und da muss man ja dann was tun, also da gibt es Unterstützung

in HTML5

durchaus

was solche Probleme

angeht, aber man muss

das ja jetzt auch dann auch irgendwie backend-seitig

hinbekommen, also es muss halt die Bilder in unterschiedlichen

Größen geben, man muss halt irgendwie

die entsprechenden

ja, Tags so rausschreiben,

das halt Source-Set-Attribut

und vielleicht

irgendwie noch andere Geschichten, Picture-Element

so gesetzt sind, wie man das irgendwie haben will

und ich war etwas überrascht,

dass es da in Django quasi überhaupt gar nichts

gibt, also da gibt es zwar

ein Image-Field, aber

das war es auch schon, das kennt dann halt irgendwie so

noch

Höhe und Breite gegenüber dem

File-Field einfach,

wenn man das verwendet, aber das

hat eigentlich nicht viel Funktionalität dafür

sozusagen für diesen

Use-Case, den man oft hat, dass man das Bild

wirklich auf einer Webseite anzeigen will

und

dann habe ich so ein bisschen geguckt und dann gibt es irgendwie so diverse

Thumbnail-Libraries und so

die sind aber alle, die haben halt

diesen Thumbnail-Use-Case

irgendwie, aber nicht, war nicht

so richtig das, was ich irgendwie da gesucht hatte

und dann habe ich dann irgendwie was selber implementiert

und dann irgendwie ein paar

paar Wochen

später oder so lief mir Django ImageKit über

den Weg, dass

quasi, also ich weiß nicht,

das waren schon bei mir so, keine Ahnung,

ein paar hundert Zeilen Python oder so, die ich da geschrieben hatte

und es war alles ein bisschen hässlich

und ich wusste auch, dass das alles nicht schön war

und das hat das halt komplett ersetzt.

Ich musste es nur noch importieren und habe dann irgendwie

meine

Spec-Dinger an die

Images herangeschrieben, sozusagen in welchen Größen

ich das haben möchte und dann war es das.

Voll gut.

Das hat dieses Problem irgendwie

für mich mehr oder weniger erledigt,

und das fand ich

sehr hilfreich und daher denke ich,

dass, ja, das ist etwas,

was andere auch interessieren könnte,

weil den Fall, dass man Bilder

auslebern will auf einer Webseite, den hat man ja doch relativ

oft. Klingt nach tollen Geheimtipps

tatsächlich. Ja, gut, ist jetzt nicht

so ein Geheimtipp, das Ding ist relativ bekannt

und das ist ein bisschen komisch, vielleicht, dass ich es nicht kannte, aber es ist

oft so, dass man... Ja, es ist oft so, dass man als Anfänger

irgendwo drüber schläupert und gar nicht weiß, wo man anfangen soll

und das ist so viel, da kennt man auch gar nicht mit,

was ist jetzt wichtig und was nicht, aber

ja, gerade für so responsive im

Experimentation, glaube ich, ist das ein super Tipp.

Ich glaube, es ist, glaube ich,

nicht nur als Anfänger so, weil

das ist total das gute Beispiel, was der Jochen

jetzt bringt, weil ich habe Django ImageKit noch nie benutzt.

Ah.

Das ist

ein so ein bisschen ein Problem

in der Django-Welt, die ist so groß, dass es

für eigentlich alles was gibt, aber man

muss es erst finden und man muss erst das finden,

was zu einem passt. Ich habe

ImageKit noch nie benutzt, ich benutze Wagtail

und da ist das immer

integriert. Wie heißt das? Ich muss das kurz hier

Shownotes notieren. Der hat auch schon

eine Bildverarbeitung.

Wagtail

ist eigentlich ein Bausatz

für Content-Management-Systemen.

Also es ist quasi ein Framework,

was nochmal oberhalb

von Django ist, was noch mehr Sachen

mitbringt und der hat eben auch gleich

dieses Bildproblem mitgelöst und deshalb

benutze ich das immer gleich für meine Bilder

auch.

Ein Wagtail, okay.

Kommt von einem Universum ins

nächste, ich glaube, da kann man Bücher

Wochen, Kurse mit füllen.

Also das ist wirklich sehr interessant.

Ja, wobei mich jetzt

auch interessieren würde, wie hat

Wagtail das Problem dann

gelöst?

Gibt es da irgendwie Default-Einstellungen, die man machen kann?

Welche Bildgrößen gerechnet werden sollen?

Und wie werden die dann tatsächlich gerechnet?

Ich meine, denn sobald ein Bild hochgeladen wurde,

werden dann die neuen Bilder erstellt oder erst beim

Zugriff und dann gecached?

Das kannst du alles einstellen.

Da gibt es ein Modul, das heißt Wagtail Images.

Um einmal kurz ein bisschen breiter auszutauschen.

Wagtail ist eine Sammlung

von Modulen, die das

Bauen von CMS-Systemen,

also von Content-Management-Systemen

erleichtern sollen. Es gab da schon

was, das heißt Django CMS, das ist relativ

alt, hat auch

mehr so diesen Flask-Ansatz. Hier sind

15 Module, baue sie zusammen, wie du

willst. Wagtail hat mehr so diesen

integrierten Ansatz.

Du musst im Wesentlichen nur noch

sogenannte Seitenmodelle

liefern, also du musst sagen, was

auf einer Seite drauf sein soll.

Für Felder. Und dann

gibt es den Wagtail-Admin, der

diese Felder eben, der diese Seiten

eben inspiziert und mit reinnimmt und

kriegst dann automatisch eben so

eine Baumstruktur mit

Revisionen und Freigabeprozess und

eben Medienverwaltung auch mit dazu.

Und die Medienverwaltung

ist relativ flexibel. Es gibt so Default-Dinger,

die eingestellt sind.

Standardmäßig ist eingestellt,

dass die Bilder beim Zugriff

erstellt werden und dann gecached werden.

Das heißt, wenn du einmal

dieses Bild in einer bestimmten Größe

angefordert hast,

dann ist es für immer

sozusagen da und wird nicht

nochmal neu erzeugt. Das heißt, es ist so ein bisschen

die Mitte zwischen den beiden

Extremen. Immer alles sofort anlegen und

immer alles neu berechnen.

Es wird berechnet, wenn es zum ersten Mal angefordert wird und dann

wird es abgelegt. Eine

Funktion, die mich hier

ungeheuer beeindruckt hat, die sie

einfach mal so eingebaut hatten, ist

Content-Aware-Resize.

Das ist so ein bisschen magisch

und man muss das ein kleines bisschen freischalten.

Aber wenn man

das einmal eingestellt hat, dann heißt

es, dass wenn OpenCV installiert

ist, dann versucht er interessante

Bildbereiche zu finden.

Und wenn ich eine kleinere Version von

dem Bild anfordere, dann wird nicht einfach

der Rand weggeschnitten und das wird nicht einfach kleiner

gemacht, sondern er zoomt dann quasi auf

diesen Bereich rein. Das heißt, wenn ich ein

Bild habe, wo eine

Person drauf ist, dann wird auch das

Gesicht der Person rein

verkleinert.

Ich habe das irgendwann mal in so einer

Vorstellung gesehen von Features in MicTale und

das ist einfach so magisch.

Die haben dieses Flag angemacht und dann plötzlich zeigt

der mir eben nicht kleine

verkleinerte Versionen von irgendwas oder

wo die Ränder dann abgeschnitten werden, sondern der

zoomt tatsächlich auf die interessanten Bereiche ein.

Und dass so etwas

in so eine Bibliothek einfach reinkommen kann,

ist eine total

geniale Sache auf der einen Seite, weil man

eben ganz viele Funktionen da mitkriegt,

aber es ist auch so ein bisschen

furchterregend, weil man eben

ganz viele solche Funktionen drin hat,

von denen man vielleicht gar nicht weiß, dass die da drin

sind oder von denen man vielleicht gar nicht will,

dass die da drin sind. Und das ist so ein

bisschen

schwierig da oft abzuwägen,

will ich sowas in

mein Projekt reinholen oder nicht.

Okay, ja.

Ich weiß jetzt natürlich nicht, wie

dieses Feature technisch umgesetzt ist, aber

da gibt es halt

quasi in HTML5

so ein, da gibt es das Picture Element

und das kann halt im Grunde, die nennen das da

Art Direction, sozusagen, dass man angeben kann, welcher

Bildbereich beim Verkleinern sichtbar bleiben

soll und so. Und wenn

Wagtail das so

benutzt, dann wäre das natürlich sehr cool.

Es könnte natürlich auch einfach das Bild

irgendwie umrechnen oder so und das wäre

halt so, das kommt halt darauf an,

wie das implementiert ist. Und eigentlich würde man

sich ja dann vielleicht auch ein Frontend wünschen,

mit dem man festlegen kann, okay, also dieser Bereich

in dem Bild ist jetzt etwas, was

nicht rausverkleinert werden

soll. Aber da habe ich eben

auch nichts gefunden. Ich habe mir natürlich, also als ich da

irgendwie mein

persönliches Blog irgendwie angefangen

habe zu schreiben, habe ich mir angeguckt, wie sieht das

eigentlich aus, wenn ich jetzt einen WordPress-Blog

aufmache? Was passiert

denn eigentlich da mit den Bildern? Und dann sieht man da so,

ja gut, also die machen das im Grunde, da werden dann halt auch ein paar

Größen vorgerechnet und die werden dann halt mit ausgeliefert

als Source-Set.

Und man hat so ein bisschen, kann man an dem Bild was machen,

man kann irgendwas beschneiden

oder man kann halt irgendwie

quasi

so ein paar Editiergeschichten

machen, aber letztendlich kann

man zum Beispiel was, was dieses Picture-Element kann,

kann man auch in WordPress alles nicht setzen.

Und es gibt eigentlich kaum

Frontends für all die

Möglichkeiten, die man jetzt mit dem Picture-Element hätte.

Und

ja, das ist halt, genau,

wenn das automatisch passiert,

dann ist halt immer die Gefahr, dass dann Dinge

hinterher zu sehen sind, die gar nicht so, wo

niemand, ja, wenn er das manuell getan

hätte, das ausgewählt

hatte. Aber

ja, also die Möglichkeiten sind natürlich schon groß.

Ja.

Du hattest eben gesagt, dass das

Probleme machen könnte, zu viele Module

in einen dann gut zu packen, die man gar nicht

möchte. Gibt es dann Sicherheitsbedenken,

die du dann da bekommst, oder?

Ja, Sicherheitsbedenken habe ich da eigentlich

relativ wenige. Dadurch, dass

da einige Sicherheits-

Standards in Django selbst umgesetzt

sind, sind so diese

ganzen Unsicherheiten, die man so

kennt, die sind da alle direkt

ausgeschlossen. Also es gibt diese

ganz bekannte Sicherheitslücke SQL Injection,

dass man eben die Datenbank dazu bringt,

Code auszuführen, der eigentlich nicht ausgeführt

werden sollte. Und das ist in Django

direkt nur

mit sehr viel Aufwand möglich, muss man so

zu sagen. Man kann es hinkriegen,

dass man so eine Lücke hat, aber man muss ja dann,

man muss dann schon die verborgene

Features benutzen, die es einem

eben ermöglichen, ein hohes SQL

auszuführen. Ein normaler

Entwickler wird niemals dieses Problem

haben, da eine SQL Injection

in Django zu haben. Es ist mehr

so eine, es ist weniger eine Frage

der Sicherheit, es ist eher eine Sache

der Handhabbarkeit.

Komme ich als Entwickler dann noch damit klar,

was ich mir jetzt alles reingeholt habe?

Oder habe ich vielleicht Sachen reingeholt,

die die gleiche Funktion

erfüllen? Habe ich vielleicht Ragtail und

Django ImageKit reingeholt?

Und

dann stehe ich da und habe

zu viele Optionen in der Hand, als dass

ich dann weiterentwickeln könnte.

Oder als dass ich dann sinnvoll

weiterentwickeln könnte,

weil es eben für

jede Sache, die ich machen kann,

eventuell mehrere Optionen gibt.

Das ist sicherlich

von außen nicht sichtbar.

Wenn die Anwendung dann fertig ist oder wenn die

irgendwie mal benutzt wird, wird der Benutzer

das sicherlich nicht sehen können, dass

das

wir da diese Probleme uns reingeholt haben,

indem wir zu viele Module reingeladen haben.

Es ist dann eher was, was die

Entwickler betrifft. Wie können wir jetzt

noch weiterentwickeln, wenn wir drei oder vier verschiedene

Sachen haben, die genau das Gleiche machen?

Ja, und wenn man dann Abhängigkeiten hat, man ist

beispielsweise in einem Teil der Applikation

abhängig von einer bestimmten Version

irgendeiner, von irgendeinem

Django-Party-App

oder so, und im anderen Teil ist man von

was anderem abhängig, dann hat man plötzlich Schwierigkeiten zu updaten.

Das macht halt die

Entwicklungsgeschwindigkeit langsam, wenn

man sich quasi so

unnötigerweise viele Abhängigkeiten

nach außen reinholt, während wenn man das halt

sinnvoll beschränkt, dann kommt

man eigentlich immer ganz gut

halt auch mit Updates klar.

Wenn ich jetzt so eine Auswahl

habe, ich habe jetzt mehrere Optionen,

wen frage ich denn da, welche von diesen Optionen

für mich jetzt die bessere wäre?

Tja, das ist eine sehr gute Frage

und wenn ich die beantworten könnte, dann

wäre auch mein Leben viel

einfacher.

Vieles davon läuft eben über

Gespräche. Man spricht mit den

Leuten in

seinen Python-User-Groups oder in seinen

Django-User-Groups oder auf den Konferenzen

oder mit den Kollegen,

mit denen man vielleicht zusammenarbeitet und jeder wird da

sicherlich Dinge wissen,

von denen man

selbst noch nie gehört hat, egal wie lange man

in dem Business drin ist. Jochen und ich sind

ja jetzt beide schon länger unterwegs und wir können uns sicherlich,

wenn wir uns da einen Abend lang unterhalten,

finden wir beide zehn Sachen, die der andere noch nicht

benutzt hat.

Es gibt eine Webseite, die heißt

Django Packages.

Die versuchen so ein bisschen, das zu sortieren.

Die versuchen so ein bisschen, da diese Themenbereiche

aufzuarbeiten und das

vielleicht auf so ein bisschen eine rationale Ebene

zu ziehen, muss man sozusagen,

wo sie einfach

sagen, okay, was gibt es denn zum Bereich

Bildbearbeitung

und wie stabil ist das und wie viele

Leute benutzen das und

für welche Django-Versionen ist das geeignet

und welche Features hat das, dass man

einfach mal so eine Übersicht

haben kann.

Ja, da kann ich mir so eine kleine Scorecard

bauen, also was ist jetzt für meinen Nutzen

vielleicht, das empfohlendste Paket.

Genau, beziehungsweise man sieht

dann einfach erstmal, was es gibt überhaupt.

Das ist oft einfach eine sehr

große Hilfe, wenn man sieht, okay, es gibt hier 15

verschiedene Bibliotheken, aber zehn davon

sind schon seit Jahren nicht mehr

geupdatet worden. Dann kann ich die gleich

aus der Betrachtung rausziehen.

Vielleicht auch, wenn ich mir die vorher schon

angeguckt hatte und die sehr gut aussahen.

Wenn es keine Updates mehr gibt,

dann ist das oft,

wenn ich mir die vorher schon angeguckt hatte,

ein Zeichen dafür, dass die Entwickler

sich es anders überlegt haben oder dass sie vielleicht

in ein anderes Projekt reingemerged sind.

Es kann nicht sein, dass auf einmal so ein Ding fertig ist.

Das kann auch sein,

aber es ist unwahrscheinlich.

Wann wird Software je fertig?

Und jede neue Version

von Django bietet natürlich auch

Möglichkeiten, Dinge wieder neu oder anders oder

einfacher zu machen und dann eigentlich

wahrscheinlich nicht immer, aber ab und zu muss man

halt doch mal was anfassen und

wenn man nichts mehr anfassen muss, dann

muss man halt

ja, eben ist es eher ein Zeichen dafür,

dass es nicht mehr richtig maintained wird.

Und ja, Django Packages

wird übrigens von einem der beiden

Autoren

in Diskurs auf Django

betrieben,

dem, der auch

Crispy Forms geschrieben hat,

was erklärt, warum es die Präferenz ist.

Ja, also die

machen da ganz viel und

ja, Django Packages

ist tatsächlich eine große Hilfe, aber

ja, so oft ist es auch schwer zu erkennen,

also ich finde das oft nicht so

einfach, wenn man jetzt irgendwie ein Problem hat,

das man gelöst haben möchte

und man jetzt hat, hat man da so eine Auswahl

von zehn unterschiedlichen Paketen,

ist es wirklich nicht einfach zu sagen,

ja, welches davon

man nehmen sollte.

Ja, ohne jetzt alle zu kennen schon.

Genau, das kann man ja auch gar nicht, man kann die gar nicht alle kennen

und selbst wenn man dann mal zwei, drei

reingeguckt hat, dann

ist das nicht so einfach zu sagen.

Ja, manchmal muss man halt dann Glück haben oder

irgendwie sich später nochmal umentscheiden,

aber das ist

tatsächlich ein großes Problem, also

wie wählt man

die Software aus, von der man

abhängig sein möchte, das ist

Ja, und jeder

baut so mit der Zeit seine eigenen

Vorlieben und seine eigenen Präferenzen auf

und die sind schwer

austauschbar. Es ist super interessant,

sich darüber zu unterhalten, aber

sie sind sehr schwer austauschbar.

Ja.

Gibt es was wie gute und schlechte

Module oder ist das eher nur eine

Präferenzenfrage?

Es gibt sicherlich gute

und schlechte Module, aber

nicht auf so einer absoluten

Ebene. Also ich könnte jetzt nicht auf irgendeinem Modul

zeigen und sagen, das ist schlecht. Wenn du das benutzt,

dann bist du ein schlechter Mensch.

Es ist eher...

Das Cookie-Law-Modul

vielleicht.

Wenn man keine Cookies eigentlich einsetzen müsste.

Wenn man keine Cookies hat.

Aber es gibt ganz viele Leute, die sowas anschalten

und gar keine Cookies haben oder so.

Ja, aber das ist ja in Django immer so. In Django hast du immer den Session-Cookie.

Session-Cookie. Also müsstest du eigentlich immer...

Musst du immer, ja.

Auch wenn du Session-Scar nicht benutzt hast, hast du immer einen Session-Cookie.

Also müsstest du eigentlich immer

das Modul direkt einschalten.

Muss man die Cookie-Warnung tatsächlich auch bei Session...

Ich dachte nur, wenn man tatsächlich ein persistentes Cookie

setzt im Browser...

Soweit ich weiß,

immer wenn du

Informationen über den Benutzer

speicherst, dann das tust du ja in dem Moment.

Okay, dann muss man es immer.

Okay, das klingt super.

Also nach...

den Themen, die wir schon immer machen wollten.

Ich glaube, Artikel 6

oder sowas ist da spannend. Da kann man einfach sagen,

hey, das muss ich machen, deswegen darf ich das auch.

Und da müsst ihr einfach mit zufrieden sein.

Ich muss euch da gar nicht Bescheid geben und gut ist.

Ja, klar. Es gibt ja auch

verschiedene Arten, wie man damit umgehen kann.

Ich habe neulich eine Cookie-Warnung gesehen.

Da stand einfach nur drin, wir müssen sie informieren,

dass wir Cookies setzen. Das haben wir hier mitgetan.

Ja.

Da kann man sich ja vor Gericht streiten, ob das ausreichend war.

Ja, aber...

Ja.

Mir fällt das schwer,

das zu verstehen manchmal, was da

bestimmte Regulierungen irgendwie eigentlich nutzen sollen.

Und Leuten, die da noch weniger

an zum Beispiel EU-Verordnungen dransitzen

in den USA, denen fällt das möglicherweise noch schwerer.

Und dann kriegt man teilweise so

fast schon passiv-aggressiv

anmutende so Geschichten so.

Willst du die Seite wirklich weiter benutzen?

Dann drück jetzt hier.

Vermeldung.

Ja. Naja, gut.

Wahrscheinlich muss man einfach damit leben, dass es halt manchmal ein bisschen nervig ist,

wenn man regelgeregelt...

Und dann haben die Leute, die das nicht verstehen,

irgendwann ausgedient. Und dann kommen Leute, die es ein bisschen besser verstehen,

die sagen dann, mach den Schrott weg.

Oder so. Hoffentlich.

Dann weiß ich es nicht. Kann natürlich immer alles schlimmer werden.

Aber ich glaube mir mal an das gute Menschen.

Ja.

Das ist ja immer Politik. Zwei Schritte vor, drei zurück.

Nein, warte mal. Drei vor, zwei zurück.

Hoffentlich.

Oder im Kreis.

Ja, ja.

Ja.

Was habt ihr denn an Neuigkeiten für Dango?

Ist euch da was eingefallen, was in letzter Zeit

da zukam, wo ihr sagtet, ey, wow,

guckt euch das unbedingt nochmal an?

Es gibt da eigentlich immer neue Sachen

zu sehen.

Dango hat vor kurzem seinen...

Ja, vor kurzem. Vor langer Zeit.

Er hat schon seit langer Zeit einen sehr schnellen

Release-Zyklus.

Entschuldigung, was heißt schnell?

Schnell heißt, dass die

sagen, alle neun Monate

kommt eine neue Version von Dango raus.

Immer ein nächstes Baby.

Genau.

Und jede dritte Version

von Dango ist eine sogenannte LTS-Version.

Eine Long-Time-Support.

Oder Long-Term-Support.

Das heißt, dass die mindestens für, Jochen,

korrigiere ich mich, drei Jahre

Sicherheits-Updates gibt.

Und das heißt, dass es

ab jetzt regelmäßig neue Major-Versionen

gibt, weil die eben dieses

Namensschema umgestellt haben. Wir sind jetzt

gerade bei Dango 2.1.

Die nächste Version, 2.2, wird

eben so eine LTS-Version sein,

die dann für längere Zeit

gültig ist.

Oder unterstützt wird, muss man so zu sagen.

Und die Version danach ist Dango 3.0.

Und üblicherweise

erwartet man ja bei

Versionssprüngen immer viele

Neuigkeiten. Und ich glaube, dass das auch hier so sein wird.

Also der Sprung von

1.11, was die letzte, was die

gerade aktive LTS-Version ist, auf 2.0,

da waren schon einige Sachen

drin, die sich deutlich geändert haben.

Was sicherlich, oder

was für mich am offensichtlichsten war, ist

der Sprung von URL zu Path,

wo sich die

Definition der verfügbaren

URLs in Django verändert hat.

Früher

in dem alten URL-Schema hat man einfach

reguläre Ausdrücke angegeben.

Und regulärer Ausdruck ist so eine Beschreibung

für einen Text, für ein Textmuster.

Und wenn dieses Textmuster gepasst hat,

dann ist eben diese passende Funktion dazu

aufgerufen worden. Man musste sich dann aber

immer noch selbst darum kümmern, dass, wenn da

jetzt zum Beispiel eine Jahreszahl drin war,

dass die zu einer Zahl wurde, weil die

natürlich aus diesem Text

erstmal nur als Text rausgekommen ist.

Und dieses Problem haben sie in

2.0 geändert. Das heißt jetzt nicht mehr

URL, sondern Path. Und man gibt eben

nicht mehr so ein Textmuster an, sondern man gibt so

ein Parametermuster an. Und sagt, okay,

an dieser Stelle soll jetzt

ein Integer stehen und den möchte ich gerne

als Parameter Ja gegeben

bekommen. Und dann wird diese URL auch

tatsächlich nur aufgerufen, wenn da eine

Ganzzahl drinsteht, die als Zahl

interpretiert werden kann.

Und das nimmt einem viel

Arbeit weg, weil

man eben nicht mehr dafür sorgen muss, dass die Parameter...

...unterpassen. Ist aber auch

erstmal ein Umdenken.

Wenn man so lange mit den

regulären Ausdrücken gearbeitet hat,

dass man sich daran gewöhnt

hat, dann verliert man oft den Blick

dafür, was überhaupt möglich ist und ob das überhaupt gut ist.

Ja, wobei ich finde,

also reguläre Ausdrücke sind natürlich toll

und man kann sie für ganz viele Sachen verwenden.

Und wenn man sich da mal so

zwei Stunden oder einen halben Tag reingefuchst hat,

dann sieht das für einen auch alles ganz natürlich

aus. Aber

wenn man das halt...

Django entwickelt, dann hat man mit diesen

URL-Patterns eigentlich immer

nur so ab und zu mal zu tun, wenn man halt

irgendwie ein neues Modul reintut oder neue

Views definiert. Und das ist eigentlich gar nicht

so super häufig. Also das kommt schon vor, aber

bei mir ist es jedenfalls so,

dass ich eigentlich fast immer, wenn ich

sowas dann, wenn ich das URL-Pattern

geändert habe, dass ich dann irgendwie in alte

Projekte geguckt habe oder nochmal Doku lesen musste.

Wie macht man das denn jetzt eigentlich nochmal?

Wie geht das mit der Gruppe?

Und dann wird das zu einem Variablen-Namen. Wo schreibt man

den nochmal hin? Kommt das P jetzt davor?

Dahinter? Oder muss ich jetzt da ein Fragezeichen...

Also das

war immer... Ich musste

es immer nachgucken. Und dann... Das ist natürlich irgendwie so ein bisschen

ein schlechtes Zeichen, weil das ist dann

irgendwie nicht intuitiv. Und das ist jetzt mit diesen

Pass-Geschichten tatsächlich deutlich

besser. Also da steht dann immer nur so

Doppelpunkt, also Int

oder String. Ich weiß nicht genau. Es gibt auch gar nicht

so viele. Es gibt noch Slug und

Pass oder so. Man kann sich selber welche

schreiben. Man kann sich selber welche schreiben? Oh, das ist

ja super. Das wusste ich jetzt zum Beispiel auch nicht.

Ist ja voll gut. Ja, man kann

sich selber welche schreiben. Es gibt verschiedene

Möglichkeiten. Du kannst entweder direkt reguläre

Ausdrücke machen. Also wenn du halt

irgendwas ganz Bestimmtes merken musst.

Oder du kannst welche, die es gibt, zusammentun.

Also wenn du zum Beispiel möchtest, dass da

ein Datum steht, kannst du eben drei so

Integer-Dinger hintereinander mit

Bindestrichen getrennt und kannst

das als Date

deklarieren. Und kriegst dann auch automatisch ein Date.

Also musst du halt das entsprechend konvertieren, aber

kriegst dann automatisch immer ein Date zurück.

Und kannst es dann von da an überall verwenden.

Oh, das ist ja großartig. Das finde ich

mal angucken, wie das geht.

Ja. Ja, siehst du, und das ist

so ein bisschen das Schöne. Das ist so ein bisschen das, was

immer passiert, wenn Django

Experten zusammensitzen.

Dann sagt einer irgendwas und der andere sagt, oh, das ist ja cool.

Das wusste ich noch gar nicht. Das muss ich unbedingt mal

anschauen. Ja.

Und das geht mir da eigentlich regelmäßig so.

Ja.

Ja.

Ja, ich weiß nicht genau, ob

für 3.0 jetzt schon so ein Thema...

Ich habe irgendwie so

am Rande mitbekommen, dass

auch für 2.0 im Grunde schon angedacht

war, ob man jetzt nicht doch

irgendwie so ein bisschen

mehr

ja, wie

Kommunikation

mit dem Client mit in Django reinnehmen kann.

Aber das geht jetzt auch schon seit einiger Zeit

irgendwie

in den neueren HTTP-Versionen, dass man quasi auch

über Websockets wieder mit dem Client

vom Server aus zurücksprechen kann.

Und es gibt diverse

Fälle, wo das ja auch total sinnvoll ist, dass man das

tut. Aber

das passt halt nicht so richtig auf dieses

ja, auf diese

Schnittstelle zwischen

Web-Server und Applikationen.

WSGI, WSGI-Schnittstelle

gibt das halt eigentlich nicht her.

Und da muss halt noch eine ganze Menge

Infrastruktur geändert werden.

Und es gab da dieses Django-Channels-Projekt.

Das gibt's ja immer noch.

Das gibt's immer noch, ja.

Und da war ja irgendwie schon

mal irgendwie quasi

sozusagen angedacht, dass in 2.0, Django 2

mit reinzunehmen. Aber das ist dann halt irgendwie nicht

passiert. Wahrscheinlich, weil zu viel angepasst werden musste.

Und vielleicht kommt das ja dann in 3.0.

Ich hab keine Ahnung.

Das ist eine ganz spannende Sache.

Das muss man sich auch mal genauer angucken.

Weil da viele Dinge möglich werden, die vorher nicht möglich waren.

Ist aber eben

technisch ganz anders. Weil wir ja nicht mehr in

dieses klassische Web-Schema reinfallen, wo

der Benutzer eben eine Webseite aufruft

und dann kriegt er die zurück. Sondern

weil es jetzt eben auf einmal eine Verbindung gibt.

Wo der Server potenziell

selbst sagen kann, hier ist was passiert, mach mal was.

Und das ist eine ganz spannende Sache.

Ja, auch technisch super interessant.

Da haben sie sich einen neuen Standard

mehr oder weniger ausgedacht. ASGI.

Was dann halt

auch neue Server-Backends erfordert.

Daphne heißt der Server. Genau, genau.

Man kann nicht einfach irgendwie Junicorn nehmen oder

den normalen Entwicklungs-Server von Django, sondern

ja. Und da ändert sich dann einiges.

Man kann schon den normalen Entwicklungs-Server nehmen, weil

der das direkt mit integriert hat.

Also wenn du Channels installierst,

dann kriegst du eine andere Variante

von Run-Server und der das automatisch

der automatische Websockets bringt.

Damit du eben in der Entwicklung den

Unterschied nicht merkst.

Aber das

Arbeiten damit ist deutlich anders, weil du eben

diese Kanäle hast und nicht mehr so dieses

Request-Response.

Schema.

Das muss man jetzt mal kurz erklären. Also ich habe jetzt

ganz kurz fast nur Warenverstand.

Request-Response-Schema, ja.

Kanäle, hä?

Was ist das?

Die

früher, als das

Web noch jung war,

war die Idee,

dass eine Webseite eigentlich nie

einen Zustand haben sollte.

Das heißt, du fragst eine URL an

und kriegst das Ergebnis, oder kriegst das,

was da auf dieser URL steht, zurück.

Und mit Error 402

Payment Required, ja. Genau.

Das hat sich dann schnell gezeigt, dass dem nicht

so ist und dass man irgendwie einen Zustand braucht.

Und man hat dann eben die Lösung gefunden, dass man Cookies

setzt. Cookies sind im Wesentlichen

der Zustand, den du mitlieferst, wenn

du eine Webseite anguckst.

Wenn du dich irgendwo einloggst,

dann wird eben der Login auf dem

Server mit dem Cookie, den du

hast, verbunden. Und jedes

Mal, wenn du diese Seite aufrufst,

guckt eben der Server, ist das ein Benutzer,

der eingeloggt ist oder einer, der nicht eingeloggt ist.

Und zeigt dann entsprechend die richtige Variante an.

Ist sehr schön,

weil man da die Seiten eben

so dynamisch generieren kann, dass sie für den

Benutzer zugeschnitten sind, der jetzt gerade

da ist. Weil wir ja wissen, wer sich

eingeloggt hat. Oder weil wir vielleicht wissen, was der

gestern gekauft hat. Oder weil wir vielleicht wissen,

keine Ahnung, was der für

einen Computer hat oder irgendwie sowas.

Ist aber immer noch,

das Schema ist immer noch Request Response.

Der Browser sagt,

ich möchte jetzt diese Seite ansehen, bitte

gib mir diese Seite. Dann macht der Server irgendwas

und gibt ihm diese Seite zurück. Und damit

ist die Arbeit des Servers schon beendet.

Und der Server hat auch keine

Gelegenheit hinterher noch zu sagen, oh halt,

ist doch was anders. Oder

vielleicht hat sich da

in der Zwischenzeit was getan oder vielleicht

passiert irgendwas. Und er wartet immer, bis der Browser

wieder fragt. Genau, die Verbindung ist dann

erstmal weg und der Browser muss dann fragen.

Jetzt haben Browser

in der Zwischenzeit JavaScript bekommen

und haben eben die Möglichkeit erhalten,

zu fragen.

Regelmäßig zu fragen.

Das ist zum Beispiel das, was Twitter macht oder das,

was Facebook macht.

Wenn da ein Newsfeed

sich aktualisiert, dann fragen die halt

alle 30 Sekunden, gibt es was Neues für mich?

Und dann sagt der Server in den allermeisten

Fällen nein. Und wenn es doch was Neues gibt,

dann gibt er eben diese Schnipsel zurück, die neu

sind oder gibt die Informationen zurück, die neu sind

und der Browser baut die dann für sich zusammen.

Jetzt wäre

es doch eigentlich von der Denkweise

her viel besser, dass der Browser nicht

alle 30 Sekunden fragen muss, gibt es was Neues?

Und ganz oft die Antwort bekommen

wird, nein, es gibt nichts Neues.

Sondern es wäre doch eigentlich besser, wenn der Server sagen

könnte, wenn es was Neues gibt,

hier, bitte nimm. Genau.

Wenn es was Neues gibt, sage ich dir Bescheid.

Und das

ist eben genau diese

Veränderung. Auf einmal hast du nicht mehr

einen Server, der nur noch Fragen beantworten

kann, der Anfragen

umsetzt und

dann die komplette Seite zurückschicken kann oder eben

auch Teile von der Seite, sondern du hast

jetzt in dem Schema die Möglichkeit,

zu sagen, es ist

ein Ereignis passiert auf dem Server

und der Server gibt

automatisch dem Client Bescheid.

Dafür brauchst du aber eine Verbindung zwischen dem Server

und dem Client, die die ganze Zeit da sein muss.

Ist das nicht dann das Netz

viel mehr ausgelastet?

Nee, es ist eigentlich weniger ausgelastet.

Weil du eben nicht die

ganze Zeit leere Anfragen schicken musst.

Gibt es was Neues? Gibt es was Neues? Gibt es was Neues?

Gibt es was Neues? Sondern du hast nur diese eine

Verbindung und die, klar, die wird offen gehalten.

Also insofern hast du eine Ressource,

belegt. Aber dieses

Verbindung offen halten ist sowieso was, was

TCP kann und das wird eben über so

Keep-Alive-Mechanismen, die sich dann

anpassen, die möglichst wenig Bandbreite

verwenden, abgedeckt.

Und du hast wirklich nur Kommunikation,

wenn auch tatsächlich was passiert.

Und das

gibt dir eigentlich zwei Vorteile. Zum einen

sparst du dir die Bandbreite, dass du die ganze Zeit

fragen musst, auch wenn nichts passiert ist.

Du weißt ja gar nicht, was passiert ist. Und zum anderen

hast du natürlich eine viel schnellere Antwortzeit.

Weil es nicht

mehr davon abhängt, wie oft der Client

fragt, dass er Updates bekommt,

sondern wenn ein Update passiert,

kann der Server sofort sagen, jetzt ist was passiert.

Das heißt, wenn ich

mir meine Chat-Anwendung schreibe

und die, das ist so das klassische

Beispiel, und der

Client fragt halt nur alle 30 Sekunden, gibt es was

Neues? Dann sehe ich auch nur alle

30 Sekunden, ob jemand was geschrieben hat.

Wenn der Server sagen kann, hier ist was Neues,

dann kann ich das sofort ausliefern. Das heißt, es wird

sehr viel

responsiver, sehr viel

schneller in der

Verarbeitung. Und Latenz

direkt verfügbar. Genau, es wird direkt

weitergeleitet und direkt verfügbar gemacht.

Und das ist natürlich was, was man heutzutage haben

möchte, diese Geschwindigkeit

in den Antworten.

Auch in ganz mondänen

Anwendungen,

immer dann, wenn ich irgendwas anzeigen möchte,

was auf dem Server passiert,

brauche ich diesen

Update-Mechanismus oder kann ich diesen Update-

Mechanismus. Also immer ein Request und das

ist halt jetzt ein Riesenvorteil.

Genau.

Ja, und ich glaube,

es gab da auch

noch Dinge, bevor man das

mit JavaScript gemacht hat,

solche furchtbaren Dinge wie Long-Polling,

wo dann der Server immer gesagt hat,

ja, nee, Moment, warte mal, ist noch nicht

ganz fertig, warte mal,

Moment.

Und dann ab und zu mal doch wieder so ein

Content-Bröckchen an den Client weitergeschickt hat.

Und es gab da

diverse furchtbare Geschichten, die gemacht wurden.

Und im Grunde jetzt

WebSockets und eine

stehende Verbindung löst all das eigentlich

relativ sauber und

ja, damit kann man wirklich tolle Sachen

machen.

Und es gab ja auch,

es gibt auch schon komplette

Frameworks und komplette

Technologie-Stacks,

die halt darauf basieren, dass man

sowas machen kann. Also wenn man zum Beispiel in die JavaScript-Welt

guckt, da Meteor oder so, die sind halt,

das ist halt vom Backend

bis zum Frontend darauf ausgerichtet, dass

man dem Client

irgendwie Dinge schicken kann.

Und damit kann man halt Sachen bauen, die

ja,

wenn man sowas zum ersten Mal sieht, relativ verblüffend

aussehen, weil sie anders

sind als das, was man so von Web-Anwendungen

gewohnt ist.

Jetzt hast du gerade wieder einen Begriff gesagt, ein Meteor.

Ja, das ist halt dieser Stack, das ist heute auch

nicht mehr so relevant, das ist immer eine Zeit lang irgendwie

halbwegs hip.

Und das ist halt irgendwie, als

Datenbank verwendet das halt irgendwie

dieses da, Dings da,

MongoDB.

Das kann halt quasi

diese Verbindungen

auch, oder wenn was irgendwie passiert,

direkt wieder an

den Server, dass dann

irgendwie ein eigenes Node.js-Basics

Dings irgendwie weiterreichen. Und deswegen

reicht es halt komplett durch an den Client.

Und du hast halt sozusagen Model-View-Kontrolle

aber mit

dem Client direkt drin. Und auf dem Client

oder auf dem Server kann der gleiche Code laufen und so.

Und das ist alles sehr schick.

Damit sieht dann halt so eine Anwendung quasi genauso aus wie

eine

ähm

ja, wie so eine Desktop-Applikation

im Grunde, was die

Reaktivität angeht. Man drückt irgendeinen Knopf

und sofort bei jemand anders in einem

anderen Browser irgendwie

sieht man, dass dieser Knopf gedrückt wurde.

Und ähm, das ist fast

ja, also

Statusänderungen sind halt sozusagen

instantan für alle, die es betrifft,

sichtbar. Und das ist halt etwas, was man normalerweise

jetzt so nicht hat. Das hat man auch bei Django nicht.

Das kann man dann schon machen, aber das ist dann halt

immer irgendwie so eine Sonder-Locker und das ist halt nicht

irgendwie in dem Framework mit,

integriert, sondern, ähm, ja,

halt immer so ein bisschen, äh, dran

vorbei.

Ähm, aber das wäre natürlich schön, wenn man das halt

direkt mit drin hätte. Und das kann natürlich gut sein,

dass das jetzt demnächst dann in einer größeren, äh,

Major-Version kommt.

Ja, ansonsten kann man sich Channels ja auch so

reinholen. Ja, kann man auch.

Also, implementiert Django dann

Module, die es vorher schon gab, oder bleibt es komplett

eigene Dinge selber? Sind da

vorher so Requests für vorhanden,

dass tatsächlich die Entwickler gucken, hey, was ist

denn so an Bedarf da, oder kommen die mit eigenen

kreativen Ideen, oder?

Ja, es, äh, es gibt, äh,

Django ist, ähm,

ein sehr großes Open-Source-Projekt.

Und, ähm... Wie viele Entwickler

gibt es da ungefähr in diesem...

Es ist schwer zu sagen, aber es gibt eine Stiftung.

Es gibt die Django Software Foundation. Also, sie sind

irgendwann so groß geworden, dass sie eine Stiftung gegründet

haben. Also Leute, die

Vollzeit auch ein bisschen dafür bezahlt werden, dass sie wie Moodle weiterentwickeln.

Genau, da gibt es so ein paar Programme,

wie das, äh, wie das, wie das möglich

ist, und die haben auf jeden Fall genügend,

äh, finanzielle Ressourcen,

um sich am Leben zu halten, und um eben dieses

Projekt, äh, am Leben zu halten.

Heißt eben aber auch, dass, äh, dass da

inzwischen relativ viel Community-Management

drin ist, weil eben die Community

so groß ist, weil es so viele Leute gibt,

die Django einsetzen,

dass es notwendig

wird, da Prozesse zu haben.

Die, der, die meiste

Weiterentwicklung kommt, glaube ich, tatsächlich aus der

Entwickler-Community, wo einer,

der es haben möchte, einfach sagt, ich mach das

jetzt mal, und dann zeige ich es allen Leuten,

und wir schauen, ob das funktioniert

oder nicht. Also es ist sehr viel da,

es ist nicht so zentralisiert,

wie man das in, in anderen Projekten vielleicht

kennt, sondern es passiert sehr viel einfach

aus der Community heraus.

Es gibt auch, äh, jedes Jahr Konferenzen

zu dem Thema, es gibt die DjangoCon,

die jedes Jahr in den USA stattfinden,

es gibt die DjangoCon Europe,

die jedes Jahr in einer Stadt

Europas, äh,

Wo ist sie nächstes Jahr, und wo war sie dieses Jahr?

Dieses Jahr war sie in Heidelberg,

im Mai. Ja?

Ach, in die Ecke.

Ja, es ist in Kopenhagen, wenn ich das richtig

weiß. Und das wird auch

immer von, äh, von der Community

organisiert, also die Software, die DSF,

die Django Software Foundation sagt, ganz

spezifisch, wir wollen, dass das Amateure

machen, weil wir eben

die, die

Community, die Benutzer mit einbeziehen

wollen in den Prozess

der Weiterentwicklung.

Und, äh, die DjangoCon Europe

ist, vor ein paar Jahren war die in Südfrankreich,

und da hatten sie so eine Insel, die hatten

einfach eine komplette Insel gemietet.

Ja. Hübsch. Das ist jedes Mal

anders, und das ist auch so ein bisschen der Reiz da dran.

Warst du da? Ich war letztens, in Heidelberg

war ich da zum ersten Mal. Ja? War,

war sehr angenehm, war eben

hinter dem, vor dem studentischen Hintergrund

Heidelbergs, äh, auch ganz nett.

Nächstes Jahr in Kopenhagen werde ich

wohl nicht dazu kommen können, aber

ich war schon mal in Kopenhagen, das ist auch sehr schön.

Und ich

kann es eigentlich jedem nur empfehlen, und jede DjangoCon Europe

ist so ein bisschen anders, weil die eben

von Leuten

aus dieser Gegend, ähm,

organisiert wird, die vorher vielleicht noch nie

so eine Konferenz organisiert haben. Also auf der nächsten Insel

schaue ich wahrscheinlich auch mal vorbei, oder? Ja.

Es lohnt sich auf jeden Fall.

Ja. Es ist super, da die Leute

kennenzulernen, und man hat auch

Kontakt da mit den, mit den

Core-Entwicklern, also mit den Leuten, die sich

tagtäglich damit beschäftigen, und das ist natürlich super.

Und gerade jetzt bei

dem Janos-Projekt, ähm, ich hab da

auch ein paar Leute kennengelernt, und hab dann auch

direkt was mit denen zusammen

angefangen zu bearbeiten.

Oh, ja, das gibt ja auf jeden Fall schon was.

Nicht gut. Ja.

Ja, ansonsten,

ich weiß gar nicht, äh,

inwiefern

das da mit reingreift,

äh, was halt auch interessant wäre,

äh, es gibt ja in Python jetzt so eine,

ähm,

äh, ziemlich schicke Syntax für

AsyncIO, und, ähm,

was eigentlich ja schon immer toll

gewesen wäre, aber nie so richtig geklappt hat, war,

äh, dass man diese Asynchronizität,

die man nach draußen hat, mit den

Requests, der Prequests,

die halt reinkommen, dass man die halt weiterreicht,

sondern, äh,

zum Beispiel an, an, an Datenbanken

oder irgendwelche APIs, die man fragt, ähm,

so momentan ist es halt so, wenn man jetzt,

weiß ich nicht, äh, um eine Seite zu bauen, zehn,

zehn Statements irgendwie an die Datenbank schicken

muss, dann werden die halt da, äh,

seriell hingeschickt und, äh, abgearbeitet

und dann, wenn die fertig sind, dann zeigt man

die Seite an, was ein bisschen doof ist,

weil das halt jedes Mal die Latenz,

also die halt durchaus ein paar, oder auch

vielleicht mal ein paar zehn Millisekunden sein kann pro

Statement, das addiert sich halt alles auf,

und dann am Schluss, äh, äh, quasi

äh, hat man halt, äh,

ist, ist die Zeit, die man

braucht, um halt quasi Content auszuliefern,

das ist ja eine wichtige Zeit, weil erst

ab da ja alles losgeht, auch wenn man hinterher,

äh, äh, Bilder parallel holen kann

oder so, äh, das geht aber nur,

wenn man weiß, wie die Build-URLs sind, das heißt,

solange nicht irgendwie ein, irgendwie Content

vom, vom, vom Applikations-Server gekommen ist,

kann gar, passiert nichts weiter.

Holst du noch mal einen Kaffee?

Genau, und, äh,

dummerweise sind halt in diesem, diese

kritischen Zeitbereich halt, äh,

äh, solche Dinge wie halt, dass

alle, äh, SQL-Statements

und Seriele geholt werden müssen, und das ist natürlich eigentlich

ziemlich blöd, und schöner wär's ja, wenn man irgendwie

alle gleichzeitig abfeuern würde, und dann

würde man dann die Halter irgendwie so einsammeln,

und dann wäre, äh, sozusagen das,

ja, längste Statement, äh, irgendwie

vielleicht das, was darüber entscheidet, wie lange es dauert,

aber, äh, man müsste nicht, äh,

irgendwie, äh, äh,

äh, quasi auf jedes Einzelne warten,

das könnte die Zeit deutlich verringern,

und, ähm,

ja, ähm, im Grunde könnte man da auch

eine ähnliche Schnittstelle verwenden wie für, für,

für, äh, äh,

für Asynchro-Initial, äh, äh, für,

für Asynchro-Geschichten nach vorne raus,

und, ähm,

da weiß ich gar nicht, ob's, äh, und bisher war das

halt immer problematisch, weil man kann's halt irgendwie mit

den vielen unterschiedlichen Geschichten, die es in Python

da gibt, machen, man kann Threads nehmen, man kann halt

irgendwie Twisted nehmen

oder so, aber...

Frido hab ich letztens kennengelernt.

Ja, das ist auch, das ist voll super, aber, ähm,

äh, ja, äh,

äh, im Grunde, jetzt hätte man halt die Möglichkeit zu sagen,

okay, da wir jetzt dann eine Syntax für haben,

dann machen wir das einfach so, und das wäre

natürlich auch eine interessante Geschichte, ich weiß auch, dass Flask,

äh, irgendwie, dass da zumindest

ein Projekt gibt, das versucht, Flask dahin umzubauen,

dass das halt alles, also,

IO-kompatibel sozusagen ist,

und, äh, bei Django weiß ich jetzt gar nicht

wieder, wie weit das ist, oder ob's da überhaupt Bestrebungen gibt,

ähm, aber sowas wäre natürlich

auch sehr nett, keine Ahnung, ja.

Ja, wüsste ich jetzt auch nicht,

aber es hört sich so an, als ob du mal ein, äh,

Enhancement-Proposal einlassen solltest.

Haha, und vielleicht

ein Fellowship beantragen, das wäre auch was.

Ja.

Ja.

Tja, tja, tja, ist wahrscheinlich auch

nicht so einfach, muss man sagen.

Ja gut, aber wenn's einfach wäre,

dann wäre es auch langweilig.

Das hätte auch schon wahrscheinlich jemand gemacht, ja.

Ja, ja.

Wir machen das nicht, weil es einfach ist, sondern wir machen das,

weil es schwer ist.

Ja.

Ja.

Ja.

Ja.

Ja.

Ja.

Was gibt's noch so an

interessanten Django-Themen?

Ach ja, vielleicht sollte man das auch noch erwähnen.

Genau, ähm,

die Art, wie dieser Podcast

publiziert wird, also, genau,

natürlich auch gedacht, so, okay,

äh, wenn ich, wenn ich da jetzt schon

irgendwie Django, äh,

entwickle, dann ist es ja eigentlich, wäre das ja

jetzt eigentlich schon ziemlich beschämend,

irgendwie WordPress zu nehmen, um

Podcasts zu veröffentlichen.

Und, äh, dann hab ich halt meinen, meinen,

äh, mein kleines Blog-Modul genommen, das, äh,

das ich mal irgendwann geschrieben hab und, äh,

da jetzt auch so Podcast-Funktionalität, äh,

äh, reingedingelt.

Und, ähm,

äh, mal gucken, wie weit das, äh, wie weit das trägt.

Äh, ähm, aber, äh,

das war alles gar nicht so schwierig, ja.

Also, zum Beispiel, wo einem Django da schon

sehr hilft bei, ist, dass, äh,

es gibt so ein, äh, äh,

Feed, ähm,

Syndication-Feed, äh,

App, also Django selbst enthält

einige Apps, unter anderem halt,

äh, Admin oder, oder Contrib,

äh, äh, also Authentication

und so Zeugs. Und halt

auch ein, ein Feed-Syndication-Framework, mit dem man halt

Feeds generieren kann. Und das ist natürlich total hilfreich,

äh, wenn man das halt nicht selber machen muss,

weil das ist irgendwie ziemlich, äh,

ziemlich fies.

Und, ähm, ja, das,

äh, das, das war eigentlich sehr angenehm.

Was natürlich irgendwie, das, was immer noch ein Problem

ist, ist, dass man dann halt irgendwie so

diverse Feinheiten berücksichtigen muss. Man muss halt gucken,

oh, äh, wenn ich jetzt,

äh, das auf dem eigentlich

einzig relevanten, äh,

äh, Katalog,

im einzig relevanten Katalog veröffentlichen will,

das ist halt der iTunes, äh, Podcast,

das iTunes-Podcast-Verzeichnis,

dann gibt es halt noch so ein paar

Spezial-Äh, Attribute, die halt iTunes

haben will, und die müssen halt richtig gesetzt

sein, und das will halt die Bilder in einem bestimmten Format

haben, oder das, das Artwork zu dem Podcast.

Und, ähm,

ja, Kategorien

müssen ein bestimmtes Format haben und so Dinge.

Ähm, da hab ich jetzt nochmal so

ein bisschen knabbern müssen, aber so,

einfach nur, dass man dann, äh, RSS

oder Atom-Feed hat, wo die, wo die

Episoden, äh, quasi,

ähm, drinstehen, das war

relativ einfach, ne, das war auch sowieso bei dem,

bei dem Blog-Teil war das halt

sehr simpel, das waren halt irgendwie, keine Ahnung,

15 Zeilen Code oder so, und dann gab's ein RSS-Feed

zu den, zu den, äh, Blog-Posts.

Das heißt, wenn ihr euren eigenen Podcast

machen könnt, könnt ihr jetzt demnächst, äh, Jochen,

das Modul dafür verwenden. Ja, kann man

tatsächlich, äh, so, sag mal so, das ist halt nicht,

äh, äh, gut dokumentiert und, ähm,

ähm, wahrscheinlich alles,

irgendwie noch ein bisschen experimentell, aber so,

ja, benutzen kann man das

schon, wenn man, äh,

ein bisschen furchtlos ist.

Und, und,

ein Bastler, ein Bastler.

Ja, das ist ein bisschen was für Bastler, muss man schon

sagen, ja.

Ja, genau, und das ist natürlich dann auch

eine gute Gelegenheit, um immer wieder was über, äh,

Django zu erzählen, wenn da, äh, irgendwelche Probleme

aufgetaucht sein sollten oder, äh, irgendwelche schönen

eleganten Lösungen möglich werden.

Ja.

Also ich, äh, ja,

ähm,

ich bin da, ich bin da eigentlich durchaus angetan. Also auch

die, die Erfahrungen irgendwie mit dem, mit dem

Blogschreiben in Django, das war auch eigentlich alles sehr,

sehr nett. Äh,

ähm, ja.

Man kann, man kommt, aber was auch

interessant ist, ist halt, äh,

ist es auf der einen Seite halt sehr, sehr viel

da schon, was man verwenden kann.

Wenn man jetzt aber tiefer bohrt, dann kommt man auch immer

relativ schnell an, an, an

Stellen, wo man sich sagt so, hä,

da gibt's noch nichts, das hat noch nie jemand irgendwie.

Und das ist halt schon so, äh,

äh, also zum Beispiel bei den Bildern

wieder, also, vielleicht gibt's da auch

was, oder ich weiß es, und ich weiß es einfach noch nicht, das kann natürlich auch

sein, aber, ähm,

äh,

dieses Django-Image-Kit löst in gewisser Weise

ein Problem, halt dieses, äh, vorberechnen

der, der, äh, unterschiedlichen Bildgrößen.

Aber wie es das tut, ist halt nicht

so richtig toll. Und da gibt's dann wieder, soweit ich weiß,

nix. Also, äh, es gibt da ja

äh, tolle Möglichkeiten. Es gibt so,

äh, ähm,

LibJPG-Turbo oder, äh,

Mods.jpg, die halt

ungefähr nochmal so mindestens

ein Drittel, äh, die Bilder

kleiner machen bei gleicher Qualität oder auch

dafür sorgen, dass, wenn ein Bild angezeigt wird

und das geladen wird, dann werden halt zuerst grobe

Geschichten angezeigt und dann halt feinere

Sachen, so, äh, das kann man mit

JPEG halt irgendwie machen. Und,

ähm, ja, ähm,

defaultmäßig wird aber Pillow verwendet. Pillow

verwendet irgendwie unten drunter ImageMagic oder so.

Und das ist alles

nicht richtig optimal. Also, da kann man zwar angeben,

wie hoch die Qualität sein soll,

aber, äh, die Bilder sind halt

nicht so klein, wie sie sein könnten, was, äh,

für die meisten Leute vielleicht kein, kein großes Problem

sein wird, aber wenn man jetzt irgendwie ein paar tausend Bilder

hat, dann macht das durchaus was aus.

Oder ich hab mal so ein, ich hab, ich hab auch einen,

einen Block mit relativ vielen Bildern drin

und war dann irgendwie, dachte ich,

dann hörte ich immer so Klagen von Leuten, die sich

das angeguckt haben. Äh, das dauert

immer so lange. Ich hab das gar nicht so gemerkt. Gut,

ich hab hier irgendwie so 100 MBit, was jetzt auch nicht so furchtbar

schnell ist, aber da, da ging das eigentlich ganz flüssig.

Und dann hab ich halt immer so in den,

äh, äh, die LibJPG-Truber

geguckt und so, und gesehen so, oh,

äh, so die ersten fünf Artikel

holen mit vielen Bildern drin, das sind halt so

200 MB. Wenn man sich das auf dem Handy

auf Edge anguckt, dann kann ich mir durchaus vorstellen,

dass das ein bisschen langsam ist.

Ähm,

ja, äh, und

da, da wär's schon schön, wenn man da halt

tatsächlich, äh, quasi default-mäßig

äh, auch irgendwie, äh,

gute Ergebnisse bekommt, aber das ist halt, äh,

irgendwie, äh, momentan jedenfalls

noch nicht so. Und da wär's natürlich auch interessant, wenn da,

äh, also man, man, man,

man stößt relativ schnell auf, auf Ecken, wo man

eigentlich was verbessern könnte, wenn man dann mal Zeit hat.

Und, ähm, ja.

Tja. Johannes, wo ist dein

größter Struggle?

Das, äh,

das, äh, das ist wie beim Johannes, das sind die Details.

Ähm, man

kommt sehr schnell so

zu den 95 Prozent des Projektes,

die eigentlich so smooth

sailing sind, die

man am ersten Tag durchkriegt.

Und an den letzten 5 Prozent arbeiten wir dann

die nächsten zwei Jahre. Also es ist, äh,

äh, es, es

ist schwierig zu sagen, welcher Bereich

am schwierigsten ist, weil es eben oft

an diesen ganz kleinen Details hängen bleibt.

Hast du da was

selber für gebaut, was du irgendwo

mal offengestellt hast?

Es gibt so ein paar Sachen, die ich, äh, die ich mal

gebaut hab und offengestellt hab. Oh, erzähl mal.

Es, äh, die sind alle schon etwas

älter.

Ähm, die meisten Sachen,

die ich in den letzten Jahren gemacht hab, waren eben für

Kunden. Und dann ist es schwierig, äh,

denen zu sagen, hier, ich hab,

äh, so und so viele Stunden dafür abgerechnet,

wie wär's, wenn wir das jetzt der Welt

umsonst geben.

Deshalb sind die meisten Sachen, die ich in den letzten Jahren gemacht hab,

eben hinter, hinter Gittern. Die müssen leider

hinter Gittern bleiben.

Eine Sache, die ich

vor Jahren mal in Python gemacht habe, äh,

ist eine Bibliothek für Kommandozeilen.

Aufrufe. Hat jetzt überhaupt gar nichts mit Django

zu tun. Ähm.

Verlinken wir natürlich auch in den Show noch.

Natürlich. Kommandier heißt die Bibliothek. Beste

Kommandozeilen-Bibliothek, die es gibt.

Ähm.

Weil es einfach ein Problem war, was mich

gestört hat. Ich wollte gerne einfache

Programme mit der Kommandozeile ansprechen.

Oder eine ansprechende Kommandozeile

anbieten können. Und

die Lösungen, die es gab, haben mich alle nicht überzeugt.

Also hab ich meine eigene gemacht.

Das,

das ist so ein bisschen das, was man, was

von einem erwartet wird. Und was man natürlich dann

auch gerne macht. Weil,

weil man ja nicht der Einzige ist, der dieses Problem

hat. Vor Jahren hat

der Python Package Index immer noch

Downloadzahlen angezeigt. Und

die sahen eigentlich schon immer ganz

gut aus für meine kleine Bibliothek.

Inzwischen zeigen sie die nicht mehr an.

Ähm. Ich weiß also nicht, wie viele Leute

das verwenden oder nicht. Ähm.

Aber so ein kleines bisschen Validierung

kriegt man da schon von der Gemeinde

zurück. Okay. Klingt

spannend. Sehr schön nutzlich.

Ja.

Da haben wir doch noch ein bisschen

Streichwerbung gemacht für die Open Source Pakete hier.

Ich bin begeistert.

Ja, für kostenlose Dinge Werbung machen.

Ist, äh, nicht so schlimm.

Durchaus erlaubt.

Äh, genau.

Was fällt euch denn noch zu Django ein? Haben wir noch irgendwas

bei den Themen offen? Was vergessen? Irgendwie was von

Tipps und Tricks, die gerade noch so

unter den Fingern brennen, die ihr gerade noch

mitbekommen habt? Ah, so viele.

Es gibt so viele Sachen. Wir könnten, glaube ich, tagelang

über Django und über

die verschiedenen Bauteile reden. Und

was jetzt, äh, besser ist und

was schlechter ist, dass es mir echt schwerfällt

eine Auswahl zu treffen. Ja, doch.

Vielleicht eine Geschichte, die ich, äh,

im Test sind ja eine relativ wichtige

Geschichte und, ähm,

äh...

Da ist jemand wach geworden. Ah, ja.

Und wütend.

Naja.

Hoffen wir mal, dass ich das recht...