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.

Sag doch 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, kannst dich ja 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 arbeiten eigentlich seither zusammen.

Gut, beim Peißenfudern, donnerstags.

Genau, jeden Donnerstagabend ab 18 Uhr.

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

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

Johannes kann, glaube ich, sogar etwas zur Geschichte von Dango 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, ja, was 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, also 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, die hieß 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.

Jacob Kaplan-Moss war das, glaube ich, der da war.

Und der von Ruby on Rails heißt David Hanmeier-Hansen.

Ja, genau.

Und die beiden haben so im Wesentlichen ihre beiden Ansätze vorgestellt.

Und haben eben Snakes und Rubys gezeigt.

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

So einmal quasi 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 Heinmeier-Hanson 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 mir jetzt so...

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

Aber Ruby on Rails geht wesentlich mehr über Konventionen.

Bei Django wird sehr viel explizit gemacht.

Also eines der 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, sage 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 ja gerade noch mal von Kontrollern geredet.

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

Wollt ihr das noch mal kurz erklären?

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

um 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

und 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 Benutzerinterface

verbinden sollen, wobei Benutzerinterface ganz

unterschiedliche Sachen sein können, also

ein Beispiel ist, man macht

irgendwie ein Weltraumkampfspiel

und dann gibt es halt

vielleicht irgendwie ein grafisches Interface,

wo man irgendwie die Raumschiffe rumfliegen sieht und so,

aber man könnte sich halt auch vorstellen, dass ein

anderes Interface nur textbasiert

ist, 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,

wie sie das halt 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 Parallel. Also die Klassen, die man benutzt

zur Verwaltung von dieser Datenbank auch.

Ja, ja, genau, genau. Und was

ein bisschen verwirrend ist, ist halt, dass

in den Django die Views Templates

heißen und die Controller Views

das, äh, weiß nicht,

ein bisschen... Ihr seid ja 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 ein Request stellen und sagen,

hey, ändert das mal. Ja, aber

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

Das geht halt nicht mehr so richtig gut.

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

Ja, verstehe.

Ja, also wofür nutzt man denn Dango, wenn ihr jetzt

gesagt habt, was da schon man mit machen kann?

Ja, im Prinzip kann man jede

Web-Anwendung damit

herstellen.

Und die Breite ist da,

also es gibt

quasi keine Begrenzung.

Die erste Anwendung, die 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.

Dann gibt es so die ganz typischen Sachen, den 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.

Und in 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?

Nee, die müssen alle drei zusammenarbeiten, weil du mit jedem dieser Teile allein hast du keine komplette Anwendung. Es wird erst dann eine 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, wird 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-Interface,

um seine Seite zu daten. Genau, 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 das

In der ersten Version kann man 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 seinen Datenbank-Dingen tun muss und die sind eben schon im Django-Admin drin und 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? Oder 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,

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

irgendwie 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 Relation 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.

Den Django-ORM auszutauschen ist halt ...

Ja, kann sein, dass das geht,

aber das will man wahrscheinlich eher nicht tun.

Bevor 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 du 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. Das kann man so,

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 Bausatz gemacht und du kannst gerne darauf aufbauen,

aber die müssen so funktionieren, wie wir das

vorgegeben haben.

Das heißt eben, wenn ich eine

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

fortlaufen 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

jetzt irgendwie jemand, der das noch nie gemacht

hat, möchte seine erste Website, einen Blog

einstellen, was 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 jetzt

ist 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, ja.

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 ein 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 Krosen.

Ja, ich mache das tatsächlich nicht so. Ich mag dieses Two Scoops of Django Buch nicht ungeheuer gerne, weil es sehr viele eigene Meinungen schon mitbringt und weil man die erst bemerkt, wenn man sich so ein bisschen mehr damit auskennt.

Ich meine, es 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 Scopes 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.

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 mache.

Das müssen wir vielleicht gleich nochmal kurz erklären, 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.

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 einwandfrei, 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-Entwicklung.

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 erst mal 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 dem Projekt konkret

sich die Lösung 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.

Machst du das dann richtig mit Stift und Papier oder auf 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 rein.

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?

Oder soll das ein Blog sein, was YouTube-Videos anzeigt? Oder 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?

Laute 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.

Das kann sich zwischendurch ja ruhig ändern. 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 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, was man jetzt sagt.

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?

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 eine Anbindung an Cash-Backend-Redis oder sowas. Man 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 und wo man Entscheidungen treffen muss.

Und das ist doch relativ überwältigend, denke ich mal, für jemanden, der eigentlich nur mal einen Blog 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, halt so

möchtest du Docker oder lieber nicht oder

brauchst du eigentlich Hintergrund-Tasks wirklich

und

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 natürlich das Problem, dass man nicht genau weiß, was passiert

ist und man halt 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, man

die man auch nur noch schwer ändern kann

und man versteht nicht so genau, was da passiert

und das ist natürlich in gewisser

so ein Nachteil. Also, 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 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

ä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 Schwierigkeiten oder

dann ist es halt nicht mehr so hilfreich, weil dann muss man wieder eine ganze Menge

von Hand ändern, was man ja eigentlich vermeiden

wollte, indem man Cookie-Catter verwendet.

Es ist 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 toll findet, dann

hilft es einem halt nicht. Dann muss man vielleicht ein eigenes Template machen.

Viele Sachen, die in dem Cookie-Cutter-Template

drin sind, gehen für mich

so ein bisschen in Richtung Produktivbetrieb.

Die nehmen einem viel Arbeit

weg, wenn man dann Produktivbetrieb hat. Die haben

Sachen drin für Content-Delivery-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 anzufangen.

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?

Meine Blogs haben nie so viel 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.

Ja, genau.

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?

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, wie 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 zu was

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.

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

und er es dann auch irgendwie

individuell spielt.

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 drauf gekommen ist, wo er sagt, hey,

Denk nochmal 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.

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

Tags so rausschreiben,

dass 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

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

da so meine

Speck-Dinger an die

Images reingeschrieben, 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 das etwas ist,

was andere auch interessieren könnte,

weil den Fall, dass man Bilder

ausliefern will auf einer Webseite, den hat man ja doch relativ oft.

Klingt nach tollen Geheimtipps

tatsächlich.

Das 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 stolpert und gar nicht weiß, wo man anfangen soll

und das war so viel, da kriegt man auch gar nicht mit,

was ist jetzt wichtig und was nicht.

Aber ja, gerade für so responsivee Implementation,

glaube ich, ist das ein super Tipp.

Ich glaube, es ist 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, ja.

Das ist 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 für die Show-Notes notieren.

Der hat auch schon eine Bildverarbeitung.

Wagtail ist eigentlich ein Bausatz für Content-Management-Systeme.

Also es ist quasi ein Framework, was noch mal 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.

Wobei

mich jetzt auch interessieren würde,

wie hat Wagtail das Problem

dann gelöst?

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

Welche Bildgrößen gerechnet werden

sollen und wie werden die dann tatsächlich

gerechnet? Ich meine, sobald ein Bild hochgeladen

wurde, werden dann die neuen Bilder erstellt oder

erst beim Zugriff und dann gecached?

Das kannst du alles einstellen.

Ah, okay.

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

Um einen mal kurz ein bisschen breiter auszuholen.

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 Rectile-Admin, 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.

Und ich habe das

irgendwann mal in so einer Vorstellung gesehen

von Features in Marktail und das

ist einfach so magisch. Die haben dieses Flag

angemacht und dann plötzlich zeigt er 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 sowas 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 es ist

so ein bisschen

schwierig, da oft abzuwägen,

will ich sowas in mein Projekt reinholen

oder nicht.

Ja, ich weiß jetzt natürlich

nicht, wie dieses Feature technisch

umgesetzt ist, aber

da gibt es

halt

quasi in HTML5

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

die

quasi

so ein paar Editiergeschichten

machen, aber letztendlich

kann man zum Beispiel, 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, wenn er das

manuell getan hätte,

das ausgewählt hätte. Aber

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

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?

Sicherheitsbedenken habe ich da eigentlich

relativ wenige. Dadurch, dass

da einige Sicherheitsstandards

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

dann schon die

verborgenen Features benutzen, die es

einem eben ermöglichen, ein hohes SQL

da 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 Wacktail 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 ich dann sinnvoll

weiterentwickeln könnte,

weil es eben für

jede Sache, die ich machen kann,

eventuell mehrere Optionen gibt.

Es 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 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-Sort-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

Und 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 musste

oder die der andere noch nie benutzt hat.

Es gibt eine Webseite, die heißt Django Packages.

Die versuchen so ein bisschen, das zu sortieren und 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, keine Ahnung, 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.

Kann ich mir so ein kleines Scorecard bauen? Also was ist jetzt für mein Nutzen vielleicht? Das empfohlenste Paket?

Beziehungsweise man sieht dann einfach erst mal, was es gibt überhaupt. Das ist oft einfach eine sehr große Hilfe, wenn man sieht, okay, es gibt hier 15 verschiedene Bibliotheken, aber 10 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 ein Anzeichen dafür,

dass die Entwickler es sich anders überlegt haben

oder dass sie vielleicht in ein anderes Projekt reingemerged sind.

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

nix mehr anfassen muss, dann

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

Duskus of 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

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 man da so eine Auswahl von

zehn unterschiedlichen Paketen,

es ist wirklich nicht einfach zu sagen, ja,

welches davon

man nehmen sollte.

Ohne jetzt alle zu kennen schon. Genau, das kann man ja auch gar nicht.

Man kann die gar nicht alle kennen und

Und selbst wenn man dann mal zwei, drei reingeguckt hat,

dann ist das nicht so einfach zu sagen.

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?

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.

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 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.

Also müsstest du eigentlich immer.

Auch wenn der Sessions gar nicht

benutzt, 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ß,

Muss man es immer? Immer, wenn du

Informationen über den Benutzer speicherst.

Und das tust du ja in dem Moment. Ah, okay.

Ja, dann muss man es immer. Mist.

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 dann 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.

Da kann man sich dann 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 nützen sollen und

Leuten, die da noch weniger in zum Beispiel EU-Verordnungen

dran sitzen 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

Meldung.

Ja,

naja, gut, wahrscheinlich muss man einfach damit leben,

dass es halt manchmal ein bisschen nervig ist, wenn Dinge geregelt werden.

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.

Man weiß es nicht, kann natürlich immer alles schlimmer

werden, aber ich glaube mir mal an das Gute

im Menschen, ja.

Ja, ist ja immer Politik irgendwie zwei Schritte vor,

drei zurück, nein, warte mal, drei früher, zwei zurück

hoffentlich.

Oder im Kreis, kann man auch mal sagen.

Ja, ja.

Was habt ihr denn an Neuigkeiten für Django?

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.

Django hat

vor kurzem seinen, ja, vor kurzem,

vor langer Zeit, hat schon

seit langer Zeit einen sehr schnellen Release-Zyklus.

Und

Entschuldigung, was heißt schnell?

Schnell heißt, dass die

sagen, alle neun Monate

kommt eine neue Version von Django raus.

Immer ein nächstes Baby.

Genau. Und

jede dritte Version von Django ist

eine sogenannte LTS-Version, eine

Long-Time-Support oder Long-Term-Support.

Das heißt, dass die mindestens für

Jochen Kurier mich drei Jahre

Sicherheitsupdates bekommen.

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

Django 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 sagen. Und die

Version danach ist Django 3.0.

Und üblicherweise erwartet

man ja bei Versionssprüngen

immer viele Neuigkeiten und

ich glaube, dass das auch hier so sein wird. Also

Also der Sprung von 1.11, was die gerade aktive LTS-Version ist, auf 2.0,

da waren schon einige Sachen drin, die sich deutlich geändert haben.

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.

Ein 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 passen. 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 irgendwie, aber wenn man das halt, wenn man jetzt 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, so wie macht man das denn jetzt eigentlich nochmal, weil ich mir das nie, 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 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 ich glaube 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.

Das 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 müssen wir mal angucken, wie das geht.

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.

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

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 und

es gibt es immer noch.

Ja. Und da war ja

irgendwie schon

mal irgendwie quasi sozusagen angedacht,

in 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, ich habe 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

Unicorn 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,

Ach, wenn man es installiert, dann kommt das Ding.

Dann kriegst du eine andere Variante von Run-Server

und der das automatisch, der automatisch WebSockets bringt,

damit du eben in der Entwicklung den Unterschied nicht merkst.

Ja.

Aber das Arbeiten damit ist deutlich anders,

weil du eben diese Kanäle hast

und nicht mehr so dieses Request-Response.

Ja.

Schema ist.

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

ganz kurz fast nur Barm verstanden.

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 zeig 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.

Das Schema ist aber 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 ihr wartet immer, bis der Browser wieder fragt.

Genau, die Verbindung ist dann erst mal weg

und der Browser muss dann fragen.

Jetzt haben Browser in der Zwischenzeit JavaScript bekommen

und haben eben die Möglichkeit erhalten,

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. 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 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, ja?

Ja, ich glaube

es gab da auch

noch Dinge, bevor man das halt

mit JavaScript gemacht hat, es gab solche

furchtbaren Dinge wie Longpolling, wo dann der Server

immer gesagt hat, ja

nee, client, 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

also 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 jetzt zum Beispiel in die JavaScript-Welt guckt,

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 das 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 so, dieser

Stack ist heute auch nicht mehr so relevant, das war mal eine Zeit

lang irgendwie halbwegs

hip und das ist halt irgendwie

als Datenbank verwendet,

dass 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 das Ding 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 und das bedeutet, also

damit sieht dann halt so eine Anwendung quasi

genauso aus wie eine

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

es passt, 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 oder 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

ja, halt immer so ein bisschen

dran vorbei.

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 Major-Version

kommt. Ja, ansonsten kann man

sich Journals ja auch so reinholen. Ja, kann man auch machen.

Also implementiert

Django dann Module, die es vorher schon gab

oder schreibst komplett eigene Dinge selber?

Sind da vorher 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?

Ja, es gibt, Django ist ein sehr großes Open-Source-Projekt.

Wie viele Entwickler gibt es da ungefähr?

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 Moodle weiterentwickeln.

Genau, da gibt es so ein paar Programme, wie das möglich ist.

Und die haben auf jeden Fall genügend finanzielle Ressourcen,

um sich am Leben zu halten und um eben dieses Projekt am Leben zu halten.

Heißt eben aber auch, 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 meiste Weiterentwicklung kommt, glaube ich, tatsächlich aus der Entwickler-Community, wo einer, der es haben möchte, einfach sagt, ich mache 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 anderen Projekten vielleicht kennt, sondern es passiert sehr viel einfach aus der Community heraus.

Es gibt auch jedes Jahr Konferenzen zu dem Thema. Es gibt die DjangoCon, die jedes Jahr in den USA stattfindet. Es gibt die DjangoCon Europe, die jedes Jahr in einer Stadt Europas durchführt wird.

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

Dieses Jahr war sie in Heidelberg im Mai.

Ja, fast in die Ecke.

Nächstes Jahr ist sie in Kopenhagen, wenn ich das richtig weiß.

Und das wird auch immer 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 Community, die Benutzer mit einbeziehen wollen in den Prozess der Weiterentwicklung.

Und die Django Con Europe, vor ein paar Jahren war die in Südfrankreich und da hatten sie so eine Insel. Die hatten einfach eine komplette Insel gemietet.

Hübsch.

Das ist jedes Mal anders und das ist auch so ein bisschen

der Reiz da dran. Warst du da?

In Heidelberg war ich da zum ersten Mal.

War sehr angenehm.

War eben vor dem studentischen

Hintergrund Heidelbergs 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

organisiert wird, die vorher vielleicht noch nie so eine

Konferenz organisiert hat. Also auf der nächsten Insel schaue ich

wahrscheinlich auch mal vorbei.

Es lohnt sich auf jeden Fall.

Es ist super, da die Leute

kennenzulernen. Und man hat auch

Kontakt da 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

Channels-Projekt, ich habe da auch

ein paar Leute kennengelernt und habe dann auch direkt

was mit denen zusammen

angefangen zu bearbeiten.

Oh, das klingt ja auf jeden Fall

schon mal echt gut.

Ja, ansonsten, ich weiß gar nicht,

inwiefern das da mit

reingreift, was halt auch interessant

wäre. Es gibt ja in Python

jetzt so eine

ziemlich schicke Syntax

für AsyncIO.

Und was eigentlich

ja schon immer toll gewesen wäre, aber nie so richtig

geklappt hat, war, dass man diese

Asynchronizität, die man nach draußen hat,

mit den Requests,

Web-Requests, die halt reinkommen, dass man die halt weiterreicht.

Sondern

zum Beispiel an

Datenbanken oder irgendwelche APIs, die man fragt.

So momentan ist es halt so,

wenn man jetzt, weiß ich nicht, um eine Seite zu

bauen, zehn Statements irgendwie

an die Datenbank schicken muss, dann werden

die halt da seriell hingeschickt und

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

quasi

hat man halt, 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 Bilder

parallel holen kann oder so.

Das geht aber nur, wenn man weiß, wie die Build-URLs

sind. Das heißt, solange nicht irgendwie

Content vom Applikationsserver

gekommen ist, passiert nichts weiter.

Holst du noch mal einen Kaffee?

Genau, und

dümmerweise sind halt in diesem

kritischen Zeitbereich halt

solche Dinge wie halt, dass

alle SQL-Statements

und Serielle geholt werden müssen und das ist natürlich

eigentlich ziemlich blöd und schöner wäre es ja, wenn man

irgendwie alle gleichzeitig abfeuern würde und

dann würde man die halt irgendwie so einsammeln

und dann wäre sozusagen das

längste Statement

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

aber man müsste nicht

irgendwie

quasi auf jedes Einzelne warten.

das könnte die Zeit deutlich verringern

und

ja, im Grunde könnte man da auch

eine ähnliche Schnittstelle verwenden, wie für

Asynchro

Asynchro-Geschichten nach vorne raus

und

da weiß ich gar nicht, ob es, und bisher war das

halt immer problematisch, weil man kann es 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 habe ich letztens kennengelernt.

Das ist voll super, aber

ja,

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 irgendwie,

dass da zumindest ein Projekt gibt, das versucht Flask

umzubauen, dass das halt alles

I.O. kompatibel

sozusagen ist. Und bei Django

weiß ich jetzt gar nicht wieder, wie weit das ist oder ob es da überhaupt

Bestrebungen gibt.

Aber sowas wäre natürlich auch sehr nett.

Keine Ahnung.

Ja, wüsste ich jetzt auch nicht, Freyhand.

Aber es hört sich so an, als ob du mal

ein Enhancement-Proposal einreichen solltest.

Und vielleicht ein Fellowship beantragen,

das du ja auch machst.

Ja.

Tja, tja, tja.

Ist wahrscheinlich auch nicht so einfach, muss man sagen.

Ja gut, aber wenn es einfach wäre,

dann wäre es auch langweilig.

Das hat ja auch schon wahrscheinlich jemand gemacht, ja.

Ja, ja.

Wir machen es nicht, weil es einfach ist, sondern wir machen es, weil es schwer ist.

Ja, was gibt es noch so an interessanten Django-Themen?

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

Genau, die Art, wie dieser Podcast publiziert wird.

Da habe ich mir natürlich auch gedacht,

okay, wenn ich da jetzt schon irgendwie Django entwickle,

dann wäre es ja eigentlich schon ziemlich beschämend,

irgendwie WordPress zu nehmen, um ein Podcast zu veröffentlichen.

Und dann habe ich halt mein kleines Blog-Modul genommen,

das ich mal irgendwann geschrieben habe

und da jetzt auch so Podcast-Funktionalität reingedengelt.

Und mal gucken, wie weit das trägt.

aber das war alles gar nicht

so schwierig. Also zum Beispiel, wo

ein Django da schon sehr hilfbar ist,

es gibt so ein

Feed

Syndication

Feed App, also

Django selbst enthält einige Apps, unter anderem

halt Admin oder

Contrib, Authentication

und so Zeugs

und halt auch ein Feed Syndication Framework,

mit dem man halt Feeds generieren kann. Und das ist natürlich

total hilfreich, wenn man das halt nicht selber

machen muss, weil das ist irgendwie

ziemlich fies.

Und ja,

das war eigentlich sehr

angenehm. Was natürlich irgendwie

immer noch ein Problem ist, ist, dass man dann halt

irgendwie so diverse Feinheiten berücksichtigen muss.

Man muss halt gucken, oh,

wenn ich jetzt

das auf dem eigentlich einzig relevanten

Katalog, im einzig relevanten Katalog

veröffentlichen will, das ist halt der iTunes

Podcast, das iTunes Podcast

Verzeichnis, dann gibt es halt noch

so ein paar Spezialattribute,

die halt iTunes haben will und die müssen halt

irgendwie richtig gesetzt sein und das will halt die Bilder

in einem bestimmten Format haben oder das

Artwork zu dem Podcast.

Und ja,

Kategorien müssen ein bestimmtes Format

haben und so Dinge.

Da habe ich jetzt immer so ein bisschen knabbern müssen, aber

so einfach nur, dass man dann

RSS oder Atomfeed hat,

wo die Episoden

quasi drinstehen.

Das war relativ einfach.

Das war auch sowieso bei dem Blog-Teil

war das halt sehr simpel. Das waren halt

irgendwie, keine Ahnung, 15 Zeilen Code oder so

und dann gab es ein RSS-Feed zu den

Blogposts.

Das heißt, wenn ihr euren eigenen Podcast machen könnt, könnt ihr

jetzt demnächst Jochen das Modul dafür verwenden.

Ja, kann man tatsächlich.

Also sagen wir mal so, das ist halt nicht gut

dokumentiert und

wahrscheinlich alles irgendwie noch ein bisschen experimentell,

aber so, ja, benutzen kann man

das schon, wenn man

ein bisschen

furchtlos ist.

ein Bastler

ein bisschen was für Bastler, muss man schon sagen

ja

genau, und das ist natürlich dann auch eine

Gutgelegenheit, um immer wieder was über

Django zu erzählen, wenn da irgendwelche Probleme

aufgetaucht sein sollten oder irgendwelche schönen

eleganten Lösungen möglich werden

ja

also ich, ja

ich bin da

ich bin da eigentlich durchaus angetan, also auch die

Erfahrungen irgendwie mit dem Blog

Schreiben in Django, das war auch eigentlich alles sehr nett

ja, man kann

aber was auch interessant ist, ist halt

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

Stellen, wo man sich sagt

so, ja, da gibt es noch nichts, das hat noch

nie jemand irgendwie und das ist

halt schon so, also zum Beispiel bei

den Bildern wieder, also

vielleicht gibt es da auch was und ich weiß es einfach noch nicht

das kann natürlich auch sein, aber

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

ein Problem, halt dieses Vorberechnen

der unterschiedlichen Bildgrößen.

Aber wie es das tut, ist halt

nicht so richtig toll. Und da gibt es dann wieder, soweit ich

weiß, nix. Also es gibt

da ja tolle Möglichkeiten. Es gibt so

LibJPG-Turbo oder

Mods.jpg, die

halt ungefähr nochmal so mindestens

ein Drittel 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. Das kann man mit JPEG

halt irgendwie machen.

Und ja,

defaultmäßig wird aber Pillow verwendet.

Pillow verwendet irgendwie unten drunter Image Magic oder so.

Und das ist alles

nicht richtig optimal. Also da kann man zwar angeben,

wie hoch die Qualität sein soll,

aber die Bilder

sind halt nicht so klein, wie sie sein könnten, was

für die meisten Leute vielleicht 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 auch

einen Blog mit relativ vielen Bildern

drin und war dann irgendwie,

dann hörte ich immer so Klagen von Leuten,

die sich das angeguckt haben. Das dauert

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

Gut, ich hab hier irgendwie so 100M mit, was jetzt auch nicht so

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

Und dann hab ich halt immer so in den

D-Blog-Truber

geguckt und so und gesehen so,

oh, wir 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 könnte ich mir durchaus vorstellen,

dass es ein bisschen langsam ist.

Ja,

und da wäre es schon schön, wenn man da

tatsächlich quasi Default-mäßig

auch irgendwie

gute Ergebnisse bekommt, aber das ist halt

irgendwie momentan

jedenfalls noch nicht so. Und da wäre es natürlich auch interessant, wenn da

also man

stößt relativ schnell auf Ecken, wo man

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

tja. Johannes, wo ist dein größter

Struggle?

Das

ist wie beim Jochen, das sind die Details.

Man kommt

sehr schnell so zu den

95 Prozent des Projektes,

die eigentlich so smooth sailing

sind, die man

am ersten Tag durchkriegt