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.
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, 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
und an den letzten 5 Prozent arbeitet man dann
die nächsten zwei Jahre.
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 mal
gebaut habe und offengestellt habe.
Erzähl mal.
Die sind alle schon etwas älter.
Die meisten Sachen, die ich in den letzten Jahren
gemacht habe, waren eben für Kunden und dann
ist es schwierig, denen zu sagen,
ich habe so und so viele Stunden
dafür abgerechnet, wie wäre es,
wir das jetzt der Welt für umsonst geben.
Deshalb sind die meisten Sachen, die ich
in den letzten Jahren gemacht habe, eben hinter
Gittern. Die müssen leider hinter Gittern bleiben.
Eine Sache, die ich vor Jahren mal in Python
gemacht habe, ist eine Bibliothek
für Kommandozeilenaufrufe.
Hat jetzt überhaupt gar nichts mit Django zu tun.
Verlinken wir
natürlich auch in den Show noch. Natürlich.
Kommandier heißt die Bibliothek. Beste Kommandozeilen-Bibliothek,
die es gibt.
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 habe ich meine eigene gemacht.
Das ist so ein bisschen das, was
von einem erwartet wird und was man
natürlich dann auch gerne macht,
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.
Ich weiß also
nicht, wie viele Leute das verwenden oder nicht.
Aber so ein kleines
bisschen Validierung kriegt man da schon
von der Gemeinde zurück.
Klingt spannend, sehr schon nutzlich.
Ja.
Da haben wir noch
ein bisschen Schleichwerbung gemacht für die
Open-Source-Pakete hier. Ich bin begeistert.
Ja, für kostenlose Dinge
Werbung machen ist
nicht so schlimm.
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
besser ist und was schlechter ist,
dass es mir echt schwerfällt, eine Auswahl
zu treffen. Ja doch, vielleicht eine Geschichte,
die ich, Tests
sind ja eine relativ wichtige
Geschichte und
Der ist jemand wach geworden.
Ja, und wütend.
Naja.
Auf jeden Fall, dass du über Tests sprichst.
Ja, das ist immer sehr schmerzhaft.
Da kommt tatsächlich direkt ein Kreis hoch.
Ja, genau.
Und da gibt es
also ich bin da
ein Fan von PyTest,
eher als von dem eingebauten Unit-Test
Framework in Python und
da gibt es dann auch diverse
Hilfspakete, die einem das erleichtern.
Irgendwie
zum Beispiel
PyTestJungle oder PyTestSugar
und
diverse andere. Und dann gibt es
noch Dinge, die einem irgendwie so
erleichtern, so ein bisschen
Fixtures und Daten zu generieren,
so Factory Boy und
weiß ich
gar nicht, was man da, ob man das
wirklich alles empfehlen sollte, was ich da so verwende.
und genau, das ist eigentlich
auch sehr praktisch. Also da gibt es halt
dann schon eine existierende Integration, da muss man
sich gar nicht so
selbst drum kümmern und
das
funktioniert eigentlich echt ganz toll.
Also
ich weiß nicht, ich glaube, du machst eher Unit-Test
oder das klassische? Ja, ich benutze
eher die in Django eingebauten, also
die klassischen Unit-Tests. Ich mag Py-Test
nicht so gerne.
Aber da gibt es doch Methodennamen
mit CamelCase.
Ja, muss man ja nicht.
Muss man nicht?
Nee, alles, was Test- heißt, ist ein Test.
Und alles andere ist egal.
Hm.
Nee, das ist ganz normal.
Dieser Testrunner ist nicht besonders gut.
Ich benutze immer den Nose-Testrunner,
aber das ist nur eine Kleinigkeit.
Ja, und man muss so Dinge machen wie,
man muss sagen, AssertEqual.
Da hat man doch auch wieder CamelCase irgendwie.
Ja, das stimmt.
diese Assert-Methoden sind so ein bisschen seltsam.
Aber das sind so Dinge, an die gewöhnt man sich mit der Zeit.
Und dann erscheinen sie einem völlig undenkbar,
dass es anders sein könnte.
Und ich glaube auch,
wir haben kein grundsätzliches Missverständnis zwischen uns.
Man sollte Tests schreiben.
Ihr habt ja beide schon brav eure Tests gemacht.
Natürlich, Coverage ist hoch genug.
Und ob die Assert-Methode jetzt Assert-Equal heißt
oder assert equals oder assert
unterstrich equal oder was weiß ich, wie sie
bei PyTest heißen mag.
Es ist einfach nur assert. Dann sagt man
irgendwie das eine gleich gleich das andere
oder so. Ja, das kannst du aber
im Unitest prinzipiell auch machen.
Aber dann kannst du halt nicht unterscheiden zwischen
du wolltest, dass da ein Fehler passiert
oder du wolltest nicht, dass ein Fehler passiert.
Aber das sind auch da wieder nur
Detailthemen, ob das jetzt so oder so
ausschaut.
Ist, glaube ich, gar nicht so wichtig.
Ja.
Aber wir kehren
wieder zurück zu diesem Thema, was wir vorhin
hatten. Jeder hat so seine Präferenzen
und mit der Zeit findet man halt
so die Sachen, die man am liebsten benutzt.
Die ausgelatschten Wege, die immer tiefer werden,
weil man immer wieder durchstiefelt. Und dann kann man nie wieder
was Neues anfangen.
Ich hoffe,
dass wir uns genügend Flexibilität erhalten haben,
um doch immer noch neue Sachen
anfangen zu können. Immer neu lernen,
heißt ja auch ganz wenig Wissen und immer
wieder von neu anfangen.
Ganz, ganz wenig Wissen, weiß ich nicht,
ob das so eine super Idee ist.
Naja, man kann sich mal wieder neue Bausteine suchen.
Ach ja, viel Software, die man so kennt,
fühlt sich schon so an,
als ob die einfach mit ganz wenig Wissen gestartet ist.
Das stimmt natürlich auch.
Aber was man generell sagen kann,
ist also testen, testen, testen.
Und wenn man das nicht macht, das ist eine sehr gute Idee. Ich habe früher immer gedacht, ich bin halt eher so jemand, der mehr so auf der, ich habe früher eher Backend oder ich komme ganz ursprünglich aus der Systemadministration und dann irgendwie über Datenbanken und dann bin ich immer weiter in dieses Programmieren reingerutscht.
Aber am Anfang habe ich irgendwie eher kurze Sachen geschrieben und fand das immer viel einfacher, wenn das irgendwie so Skripte waren, die nur so auf einer Bildschirmseite passen oder vielleicht ein paar hundert Zeilen haben oder so, das war, da habe ich mich wohl gefühlt, weil das war etwas, was kann man halt so komplett überblicken und wenn da sich irgendwas dran ändern soll, dann kann man das auch tun, ohne dass es hinterher schief geht.
Und immer, wenn ich dann versucht habe, größere Sachen zu schreiben
und dann halt Features hinter sehr
dazukamen oder sich geändert haben,
dann sind immer furchtbare Sachen passiert. Oder nicht immer,
aber häufig genug,
dass es irgendwie
unangenehm war,
schreckliche Dinge passiert.
Die Welt geht unangenehm, ja.
Ja, und seit
ich irgendwie Tests schreibe, ist das
eigentlich nicht mehr so schlimm.
Seitdem
nicht mehr so schlimm.
Das passiert leider immer noch.
So ganz lässt sich das nicht verhindern, aber
es ist,
ich fühle mich jetzt wohl dabei, auch
längere Sachen zu schreiben, auch wenn ich jetzt nicht
mehr quasi die Details anderer
Module
oder anderer Apps, die
da auch noch Dinge tun,
wenn ich die nicht mehr so verstehe oder auch lange nicht mehr
daran gearbeitet habe, dann habe ich jetzt nicht mehr
so ein Problem, irgendwas zu ändern, was die betrifft.
Wenn ich hinterher die Tests durchlaufen lasse und
die sehen gut aus, dann kann ich
ja schon relativ sicher sein, dass da nichts total Schreckliches
passieren wird.
Und wenn man das halt nicht hat, dann
hat man ein großes Problem, weil
wenn man Tests hat, dann weiß man, wenn man ein Update
macht oder wenn man jetzt eine Version von einer Bibliothek
ändert oder man ändert irgendwas völlig
harmloses, von dem her man denkt, das kann eigentlich überhaupt keine Auswirkungen
auf irgendwas anderes haben und dann
füllt man die Tests aus und dann schlagen vier Tests Fail
und einer davon schlägt Fail und man denkt sich so
oh Gott, das hätte nie passieren dürfen.
Dann weiß man,
ja, das wäre jetzt, wenn man keine
Tests gehabt hätte, dann wäre das ein wirklich fieser
Bug gewesen und teilweise
sind die halt so, dass man sich hinterher auch sagt,
also da kommt man nicht drauf, dass
das irgendwie die Auswirkungen hatte, das
hätte man jetzt gar nicht,
also durch lange Meditationen über diese
Änderungen hätte man das nicht wirklich
rausbekommen können und
wäre ihm wahrscheinlich auch gar nicht aufgefallen und dann
irgendwann fliegt es dann im, ja.
Wäre es dem User aufgefallen oder
dann hätte der sich beschwert, was
schon ziemlich schlimm ist oder noch schlimmer
es wäre irgendwie eine Sicherheitslücke oder so gewesen, also
Also man fühlt sich da deutlich besser,
wenn man Tests hat und das irgendwie so praktiziert.
Und seit ich damit angefangen habe,
fühle ich mich da irgendwie deutlich wohler mit allem.
Also, ihr hört, brav testen und eure Tests fern benutzen.
Verschreibt ihr denn zuerst eure Tests
oder schreibt ihr erst den Code?
Da kann man sich, wenn man die Frage beantwortet,
kann man sich nur in den Nesseln setzen.
Weil du so viele Zusendungen kriegst,
dass man es anders machen sollte.
Zusendungen übrigens gerne an
hallo-podcast.de
Du könntest jederzeit Fragen, Anmerkungen stellen.
Ich habe gerade so wunderschön reingepasst.
Keine Aussage von dir, Johannes?
Ich schreibe meinen Code zuerst
und schreibe die Tests hinterher.
Und das schockiert viele Leute.
Ich mache nicht TDD.
Ich komme überhaupt gar nicht klar mit TDD.
TDD ist Test Driven Development.
Genau, Test Driven Development heißt,
Man schreibt zuerst Tests und ausschließlich Tests und dann schreibt man ganz genau so viel Code, dass diese Tests erfolgreich werden und nicht mehr.
Und die Idee dahinter ist eben, dass man immer automatisch 100% Test Coverage hat.
Alles, was man an Code geschrieben hat, ist automatisch getestet, weil man den Test vorher geschrieben hat, bevor man den Code geschrieben hat.
Klingt logisch.
Das Problem für mich ist, dass Tests sind etwas,
auch wie der Jochen das soeben beschrieben hat,
die fixieren die Funktionalität eines Programms.
Die sorgen dafür, dass ich weiß,
das funktioniert genau auf diese Art und Weise.
Ich weiß aber oft gar nicht, wie ein Programm funktionieren soll,
wenn ich anfange, das zu schreiben.
Und dann fällt es mir sehr schwer, diesen Test dafür zu schreiben,
wenn ich noch gar nicht weiß, wie ich es dann tatsächlich machen möchte.
Wie ich denn möchte, dass es am Ende ausschaut.
Und deshalb fange ich üblicherweise an Code zu schreiben und dann hat man halt irgendwie so ein paar Sachen umgesetzt und dann fange ich an die Tests dazu zu schreiben und dann eben sozusagen das so weit aufzubohren, dass alles drin ist, was ich haben möchte und die Tests.
Was ist denn das Gegenargument? Bist du nicht kreativ genug, dir vor die Tests auszudenken oder hinterher wirst du dann zu faul und die Tests fehlen am Ende?
Nee, ich glaube, es ist einfach nur ein gewisser Arbeitsmodus, der eben zu manchen Leuten passt und der zu manchen Leuten nicht passt. Und ich bin immer sehr beeindruckt, wenn Leute TDD machen und wenn die das zeigen und ich weiß auch, dass das super gut funktioniert, weil die Vorteile eben da sind.
man hat eben immer Tests
geschrieben, bevor man Code überhaupt
schreibt. Also aller Code, den man schreibt, ist getestet
automatisch. Heißt auch nicht,
dass der 100% failsafe
ist, aber man kann auf jeden Fall sicher sein, dass die
Dinge, die man in die Tests geschrieben hat, so funktionieren.
Wie sie funktionieren sollen.
Wie machst du das, Jochen?
Ich muss gestehen, tatsächlich
genauso quasi.
Also,
ja, ich habe ja auch schon häufiger mal, oder ich habe es auch tatsächlich
schon probiert, irgendwie zuerst die Tests zu schreiben und dann
den Code, aber
also es gibt da eben
zwei Dinge für mich. Also eine Sache ist halt
auch, dass ich oft
nicht weiß, wo es hingehen soll und
ich fange sogar, das ist auch vielleicht noch
eine ganz interessante Empfehlung,
oft auch gar nicht jetzt
tatsächlich ein Modul
anzuschreiben, wenn ich irgendwas schreibe.
Also quasi in einer Django-App
so ein Django-Projekt oder
eine Django-Applikation besteht üblicherweise
aus einer Reihe von Django-Apps, die man halt schreibt
und dann gibt es halt Third-Party-Apps, die man sich von irgendwo
importiert, wenn man es installiert hat
und dann gibt es halt welche, die man selber schreibt.
Also User-Verwaltung ist
üblicherweise ein Teil und dann kann halt
irgendwie, keine Ahnung,
ein bestimmter Teil der Webseite kann halt irgendwie ein anderer Teil
sein oder so.
Und
üblicherweise schreibt man halt in diesen Apps
irgendwas, wenn man jetzt eine Django
Applikation schreibt.
Aber oft, wenn ich nicht weiß,
wie ich überhaupt irgendwas
machen möchte, dann mache ich nicht das, sondern
ich schreibe Sachen in einem Notebook.
Das ist
Das ist auch der Hintergrund, der da durchkommt.
Ja, ja, natürlich. Also ich mache halt
eher so eigentlich
noch mehr als Django
so Data Science.
Du meinst ein Jupyter-Notebook? Genau, ein Jupyter-Notebook.
Da gibt es auch
ein sehr
empfehlenswertes Paket, nennt sich
Django Extensions.
Da sind einige schöne Sachen dabei.
Unter anderem halt ein Entwicklungsserver,
eingebauten Debugger hat, wo man dann halt direkt
im Traceback quasi eine Debug-Shell bekommt.
Da gibt es
noch andere Dinge, Shell Plus, wo dann halt
diverse Imports schon mit drin sind.
Was das Ding auch hat, ist, man kann
halt
Shell Plus minus minus Notebook oder so
starten und dann wird ein Notebook-Server hochgefahren
und zwar mit einer Django-Shell.
Und dann hat man halt all den Kram, den man in Shell Plus hat,
halt in einem Jupyter-Notebook.
Und das ist halt sehr nett. Und dann kann man halt einfach mal
eingehen und mit den Dingen spielen und einfach mal
so Sachen so sketchmäßig
implementieren und gucken, ob es funktioniert.
Und erst, wenn ich weiß, okay, so
funktioniert das irgendwie, was ich vorhabe,
schreibe ich das quasi tatsächlich
in eine Django-App rein
und gut,
es gibt Dinge, bei denen geht es nicht anders.
Jetzt, wenn man... Oh, Gesundheit.
Ja, danke.
Wenn man Modelle hat und die Datenbank
ändert sich, dann muss man das halt
irgendwie in der Models-PY machen
und dann muss man halt irgendwie Migrationen ausführen.
Oh, Migration, das ist ja auch so ein Thema.
Aber wenn es um irgendwie Logik oder so geht,
dass die richtig funktioniert
oder man einfach nur hinkriegen möchte,
dass das jetzt, oder wie man das elegant hinschreibt,
man weiß oft nicht, wie man das elegant hinschreibt.
Und wenn man Sachen ausprobiert,
dafür ist ein Notebook echt total super.
Kann man halt so lange probieren, bis es geht.
Muss nicht dauernd irgendwie sich darum kümmern,
dass man auf der Webseite ist, irgendwas anklickt
oder irgendwie den Entwicklungsserver neu startet,
beim Syntax-Error steigt der dann aus und dann muss man
wieder neu starten.
Das ist alles so ein bisschen langsam
und im Notebook ist das alles viel schneller.
Und dann, wenn das halt irgendwie funktioniert, dann übertrage ich
die Funktionen, die ich halt im Notebook drinstehen habe,
halt in meine
anderen Files und dann
schreibe ich Tests halt irgendwie.
Das ist
der eine Punkt. Der andere Punkt bei Tests ist halt,
dass es Dinge gibt, die sind
sehr schwer zu testen. Es bringt aber gar nicht
so furchtbar viel, das zu testen. Also das ist
auch sowas. Wenn man jetzt tatsächlich,
ich habe auch eigentlich fast nie 100% Testabdeckung,
sondern meistens eher so 70
bis 80 oder so.
Was auch
nicht so schlecht ist, was halt, ja, es ist halt irgendwo,
ich weiß nicht genau, wo der Sweetspot ist,
vielleicht ist er bei noch ein bisschen mehr, vielleicht ist er bei
ein bisschen weniger.
Ich finde, es ist halt
im Grunde wichtig, dass man so viele Tests hat,
dass einem, wenn was schief geht, das auffällt,
aber wenn man jetzt so viel
Tests hat, auch wenn man so viel
Zeit in den Tests verbringt, hat man halt das Problem, dass man
sich dann schon sehr, sehr festgelegt hat und das hinterher schwer
ändern kann.
Und die Frage ist, ist es das wert?
Wenn das halt gar nicht mehr so viele Fehler
fängt, weil ich irgendwie anfange,
weiß ich nicht, also Dinge, die ich selten teste,
sind halt, funktioniert das URL-Routing?
Das kriege ich eigentlich auch ohne Tests mit,
wenn das nicht mehr funktioniert.
Oder auch die Tests schlagen halt
Fehler, die auf die entsprechenden Endpunkte gehen.
Oder das Django-Admin
Geschichten, die teste ich auch
eigentlich eher selten.
Also die Logik schon,
aber nicht, ob Ant-Admin überhaupt geht.
Überhaupt sollte man nicht unbedingt testen,
die halt schon eigene Pakete sind, weil die haben schon
Tests und so.
Und für mich ist
der Sweet Spot beim Testen eher so bei
70, 80 Prozent.
Ein Test,
die man einfach schreiben kann.
Das ist ja auch immer so ein Problem, wenn die Tests zu kompliziert werden.
Also gut, manchmal schaffe ich
das nicht. Manchmal schreibe ich auch Tests, die komplizierte
Dinge tun und dann hinterher ärgere ich mich immer,
wenn die fehlschlagen und ich dann nicht mehr
weiß, was testet das überhaupt?
Warum brauchst du Dinge?
Was macht das für komische Sachen?
Du brauchst Tests für deine Tests.
Genau, und das will man natürlich eigentlich vermeiden,
weil dann wird es schwer.
Wie kriege ich überhaupt so eine Test-Coverage raus?
Also woher weiß ich denn,
wie viel von meiner Funktion getestet wird?
Zähle ich dann einfach die Funktionen,
schreibe für jede Funktion eine Test-Funktion
und gucke dann und dividiere dann in Quotienten?
Ja, da gibt es Tools für.
Also da gibt es ein Tool, das heißt Coverage.
Ein kreativer Name.
der gibt einem im Wesentlichen für jede Programmzeile
an, würde die von einem Test berührt
oder nicht. Und
die Anzahl der Gesamtzeilen in einem Programm
geteilt durch die Anzahl der getesteten
Zeilen. Okay, also ganz easy.
Ganz easy. Das macht einmal eine
Ausgabe auf der Commando-Zeile, aber es
macht halt auch, es erzeugt so irgendwie HTML
und wenn man das im Browser aufmacht,
dann, wenn man auf die
entsprechende Zeile drückt, dann sieht man halt auch
eine Ansicht des Codes und sieht
dann halt irgendwie farblich markiert, welche
Codezeilen halt noch nicht getestet sind.
und dann kann man halt relativ schnell sehen, wenn das halt Zeugs
ist, wo man relativ sicher davon
ausgehen kann, dass es sowieso funktionieren wird, wie
URL-Confs oder... Die Stereo-Methode.
Ja, dann muss man...
Jedes Modell hat eine Stereo-Methode und das
wird nie auf 100% Coverage, wenn man diese
Methode nicht testet, aber die ist völlig irrelevant.
Ja.
Auf der anderen Seite, wenn man dann halt durchscrollt und sieht dann
halt irgendwie ein komplexes
Ding, ein Algorithmus, der irgendwas macht
und der ist gar nicht getestet, dann sollte man
da sollte man dann vielleicht mal einen Test schreiben.
Und so kann man, so gehe ich jedenfalls vor. Ich gucke mir halt
immer an, was die größten Code-Teile, die halt am meisten
Funktionalität irgendwie haben. Wenn die nicht geteilt
sind, dann fange ich halt da an.
Es gibt auch ganz viele IDEs, die das integrieren,
wo du quasi diese Ansicht in der IDE hast.
Wenn du eine Testansicht haben kannst, wo du
eben siehst, welche Zeilen durchgelaufen sind.
Welche IDE nutzt du? Ich benutze
PyCharm.
Vor ein paar Jahren
sind die plötzlich groß
geworden.
JetBrains ist
so eine Variante von
von einer IDE, die hieß
früher IDEA.
Die gibt es auch immer noch. Das ist eine Java-IDE.
Es ist schwierig, da eine Empfehlung
zu geben, weil auch da die Vorlieben sehr weit...
Deine Vorliebe hat natürlich auch Interesse.
Genau. Und es ist auch eine Gewöhnung.
Ich weiß auch, dass es nicht die beste IDE
ist und ich weiß auch, dass sie nicht
ungeheuer billig ist.
Aber
ich benutze halt das, was ich gewöhnt bin.
Also Community Edition kann man vergessen.
Die Community Edition kann man nehmen, aber die hat
nicht so eine gute Django-Integration.
Gerade was Django angeht, ist tatsächlich
die Professional Edition deutlich besser, weil
die viele von den Sachen,
die in Django so ein bisschen implizit
sind, trotzdem weiß.
Gerade was die
Datenbank angeht, ist da sehr viel drin.
Oder Templates auch. Die Template-Syntax
ist in der Community Edition nicht drin.
Ist ein bisschen schade,
aber so ist es normalerweise.
Migration hast du noch
angesprochen, Jürgen. Ja, ja,
Das ist auch etwas, was halt...
Was ist das?
Genau, was ist das?
Also oft hat man halt das Problem,
wenn man jetzt so eine Applikation entwickelt,
man hat ein neues Feature oder so
und dafür muss man jetzt auch das Datenmodell ändern,
weil man irgendwas Neues abspeichern muss oder so.
Oder man muss halt eine bestehende Datenstruktur irgendwie ändern,
weil sich die Beziehungen der Daten untereinander irgendwie ändern oder so.
Und dann ist die Frage, wie macht man das eigentlich?
Das gab es in den ersten Versionen von Django,
gab es das nicht. Da konnte man Datenbanken
nicht ändern. Du musst dann mal manuell
ändern in der Datenbank selber
oder halt einmal komplett resetten.
Ja, genau.
Dann gab es irgendwann
ein Modul,
das nannte sich South.
Das hat dann damit angefangen.
Ich weiß gar nicht, wo die Idee dafür herkommt.
Für den Namen?
Einmal für den Namen nicht.
Und ich weiß auch gar nicht, wo das...
Das ist, glaube ich, Vogelmigration, dass die in den Süden ziehen.
Ach so, Vogelmigration.
Ja, schlau.
Ist nur ein bisschen schlecht, wenn man danach googeln will.
Ja, es ist eher Django South.
Jedenfalls, diese Bibliothek hat dieses Problem gelöst,
in dem man eben gesagt hat,
okay, ich möchte jetzt eine Zustandsänderung aufzeichnen.
Und diese Zustandsänderung,
die konnte man dann auf eine Datenbank anwenden.
Also die hat einfach tatsächlich diese Tabellen,
die da drin sind, verändert.
Die haben ein Alter Table gemacht
oder Zeilen gelöscht
oder was auch immer notwendig war,
um eben diesen neuen Datenbankzustand
hinzubekommen. Nicht den Datenzustand,
also nicht, was da in der Datenbank drin ist, sondern die
Struktur, die strukturelle
Anlage der Datenbank.
Und das ist so ein wichtiges Problem,
dass es irgendwann in Django Core gewandert ist
und ist jetzt eines der wichtigsten Module
in Django. Ja, ja, auf jeden Fall.
Also ich erinnere mich da auch
mit
Schrecken an Zeiten,
also
wo dieses Problem, also jetzt
mit integrierten Migrationen und so
ist es halbwegs okay, also es ist auch immer noch
ein Stößer auf viele Fälle, wo es
eklig werden kann und wo man auch für die Migration
dann Tests schreiben muss und so,
aber wenn ich mich da
an frühere Zeiten zurückerinnere,
wo wir jetzt gar nicht sowas wie Django verwendet hatten,
zum Beispiel
bei Firmen, bei denen ich gearbeitet habe, sondern
irgendwie selbstgebaute
Webframeworks
oder Dinge, die es schon gab, die aber
sowas alles nicht drin hatten, da war
das immer irgendwie
eine problematische Geschichte. Da hat man
dann halt irgendwie
das getestet, irgendwie lokal
oder auf einem Entwicklungssystem oder einem Staging-System
und hat das dann funktioniert.
Dann hat man das Problem, wie synchronisiert man die
unterschiedlichen Schema-Versionen, was
passiert auf dem Produktionssystem,
dann
hat man das irgendwie durchgeführt und dann ist auf dem
Produktionssystem aber was anderes passiert, als man
irgendwie eigentlich erwartet hatte und dann
musste man halt wieder nachgucken, was ist denn da
jetzt eigentlich passiert und es gab gar keine
formalisierte Sicht
auf dieses, was passiert
da jetzt gerade, sondern das ist halt ein Skript, das man ausgeführt
hat und dann
ja, das ist dann aber
möglicherweise auch nicht
so mit dabei,
sondern das ist bei irgendeinem Entwickler auf dem Rechner
und so und der connectiert sich halt
in irgendeinem Notebook und das
macht dann halt irgendwas
und das ist halt schön, wenn man das halt formalisiert hat,
weil bei Django hat man dann halt irgendwie ein Verzeichnis
Migrations, in dem die alle dringend liegen, wo man
reingucken kann, was da passiert, in der Datenbank
selbst wird festgehalten, welche schon
ausgeführt worden sind und an welcher Stelle man
sich befindet und man kann halt auch leicht wieder
vor- und zurückspulen sozusagen, man kann
halt sagen, migrate
und dann halt eine Nummer einer Migration
angeben, zu der man zurück möchte und
dann rollt sich die Datenbank in diesen Zustand
wieder zurück, dann kann man halt, wenn man
zum Beispiel gesehen hat, dass das, was man gemacht hat, war
Blödsinn, dann rollt man halt das Ding
zurück, löscht die Migration und macht halt eine andere
und ja, das
ist eine sehr, sehr praktische Geschichte und
führt halt dazu, dass man dieses ganze
Problem irgendwie so halbwegs in den Griff
bekommt und es gibt
zumindest die Tools an die Hand, mit denen man das in den Griff
bekommen kann, was halt
in
wenn man das halt nicht so macht, sondern
von Hand oder selbst gestrickt halt
doch viele böse Falschtricke
für Leute bereithält und die dann
also relativ unvorbereitet reinlaufen
und das ist halt eine Geschichte, die man auf jeden Fall
wissen sollte, dass das gibt
Ich glaube auch, dass gerade
Third-Party-Apps dadurch überhaupt erst richtig
möglich wurden, dass man eben diese
Migrationen mitliefern konnte, weil
sonst immer in jeder
Bibliotheks-Update musstest du
von Hand diese Struktur anpassen
oder eben diese Skripte haben, die das irgendwie
machen und hoffen, dass die funktionieren auf deiner Datenbank
genauso wie sie bei dem
Entwickler funktioniert haben
und heute weißt du einfach, wenn du eine Bibliothek installierst
die bringt ihre Migration mit und die funktionieren auch.
Aber klar, es ist auch so ein
Fallstrick, wenn man zum ersten Mal
eine Django-Anwendung startet und dann schön seine
Modelle geschrieben hat und dann
Operational Errors bekommt, weil die Datenbank nicht da ist.
Stolper ich auch regelmäßig noch drüber,
weil ich vergesse, meine Datenbank
zu migrieren.
Dann gibt es keine automatische
Erinnerung, also die musst du dir dann selber...
Der Operational Error ist die automatische Erinnerung.
Ja, das hört sich auf jeden Fall so an.
Da könnte man Django für alles mögliche
einsetzen. Für große Projekte,
für kleine Projekte, für schmale, schlanke.
Ich weiß nicht, haben wir eigentlich schon
irgendwelche Beispiele genannt für
Django-Anwendungen, die man vielleicht so
kennt? Kennst du denn welche?
Ja, ist ja zufällig.
Ich kenne bestimmt auch nicht alle, aber ich glaube,
eine der größten Django
Implementationen
hat Instagram
oder hat Instagram? Aber haben sie abgelöst.
Haben sie abgelöst? Oh je, dann war das jetzt kein
Nee, aber sie sind natürlich sehr groß damit gewachsen.
Und das ist natürlich richtig.
Was machen die denn jetzt, weißt du das?
Weiß ich nicht genau, nee.
Es ist üblicherweise so, dass wenn man solche Standardlösungen einsetzt
und dann so groß wird wie Instagram zum Beispiel,
dass man dann auf einmal auf Probleme trifft,
die eben durch Standardlösungen nicht mehr abgedeckt werden
und dass man dann anfängt, seine eigenen Dinge zu bauen.
Das haben die ganzen großen Firmen
machen das ja alle. Die betreiben alle ihre eigenen
Web-Server. Die haben alle ihre
eigenen Datenbanken geschrieben. Die haben alle ihre eigene
Infrastruktur geschrieben, weil ab einer gewissen Größe
sind die Standardlösungen einfach nicht mehr wichtig.
Und bei Instagram war es genauso. Die sind sehr
groß geworden mit Django und haben es dann abgelöst.
Soweit ich weiß.
Fällt dir noch ein anderes Beispiel ein?
Einem von euch?
Es gibt viele kleine Sachen,
die damit laufen.
Man sieht
das von außen natürlich nicht. Man sieht in der
Web-Anwendung nicht an, ob es in Django geschrieben ist
oder nicht.
Und deshalb muss man
so ein bisschen darauf vertrauen, dass
die Entwickler einem das mitteilen.
Es gibt ein System, das heißt
Pre-Tix. Das ist ein
Ticket-Verkaufssystem. Also wenn man
ein Konzert veranstaltet und Tickets verkaufen möchte,
das ist in Django geschrieben. Die sind auch
sehr aktiv
bei den Django-Cons.
Ja.
Ne, ansonsten,
also ich weiß das halt auch noch.
Das ist so eine Zeitung in Amerika.
Ja, genau.
Das waren die ursprünglichen Entwickler von Django.
Also es kommt aus dem Zeitungsumfeld.
Also auch als Blog-Plattform für Vertrieb von neuen News-Artikeln?
Ja, die haben ihre komplette Zeitungs-Webseite damit organisiert im Wesentlichen.
Also so ist es, das ist so die Entstehungsgeschichte.
Das ist aus einer kleinen Stadt in Texas, Lawrence.
wo eben zwei Entwickler gesagt haben, wir machen das
jetzt einmal richtig, anstatt immer wieder
PHP-Kram zusammenzubasteln.
Haben sie einmal das Problem richtig
gelöst und durften es dann irgendwann
veröffentlichen. Und das System
heißt jetzt Django. Und soweit ich weiß,
wird es da immer noch eingesetzt.
Spannend.
Ja, habt ihr
noch was beizutragen zum Django oder
würdet ihr sagen, wir haben das Thema jetzt so weit
durch?
Es gibt noch
viele Dinge, die man machen könnte, aber nichts Konkretes.
Wenn wir irgendein Thema nochmal besprechen sollen,
dann sag gerne Bescheid, dann machen wir genau
da weiter. Es gibt ja auch diese E-Mail-Adresse,
an die man Fragen schicken kann. Genau,
hallo at python-podcast.de
Ja.
Ne, mir fällt da
jetzt auch tatsächlich,
man kann bestimmt auch noch
über diverse
Bereiche in
Django wieder eine eigene Sendung
machen. Ja, eigene Episoden.
Episode über den ORM oder Episode über
Template-Sprachen oder so. Ja, oder auch
über ganz einfache Sachen wie die Formular-Integration
oder wie
die Session-Integration oder
ganz einfache Dinge, die
man so für
ganz normal hält, die aber
für euch ist alles ganz normal,
easy und aus dem Ärmel.
Man kriegt das halt automatisch mit.
Wenn man Django einmal startet, dann ist es schon da
und man muss sich nie Gedanken darüber machen.
Aber es ist super interessant, was damit alles geht
und was vielleicht nicht geht und wie
es geht. Und
super spannende Sachen.
Was man vielleicht noch erwähnen sollte, also dieser ganze
Web-Stack, also Web ist halt so ein bisschen
was man halt leider
auch immer wieder sieht, dass es nicht so richtig
aus einem Guss, also wenn man sich jetzt
beispielsweise anschaut, wenn man mit Xcode
jetzt iOS-Applikationen
erstellt oder so, dann ist das halt
auch Model-View-Controller, aber es ist halt
eigentlich sehr
schön irgendwie so gebaut,
dass es halt alles von dem
Finger, der irgendwo draufklickt, bis zu
dem Datenmodell halt alles
schön ineinander greift und funktioniert.
Das ist im Web leider alles nicht
so wirklich und das fällt einem dann halt auch
öfter auf oder auf den Fuß, weil
man halt ganz so viele unterschiedliche
Sprachen
Layer hat, die irgendwie
miteinander interagieren müssen. Jetzt der
Django-Teil ist ja sozusagen nur der
Teil der Web-Applikation,
die sich jetzt auf einem Applikations-Server
befindet und da irgendwie, und der Datenbankteil
ist halt jetzt auch noch irgendwie mit drin, sozusagen.
Aber, oder
es rennt halt auch HTML nach vorne raus, aber es ist halt
auch das HTML, also die Templates selber,
ist das jetzt, ist HTML ein Teil von
Django? Eigentlich eher nicht.
Das ist eigentlich nochmal eine etwas andere Welt.
Wie sieht das hinterher aus?
Dazu braucht man dann CSS, das ist
zwar auch irgendwie in Django drin, man kann halt,
es gibt da, man kann SAS oder LESS
oder was auch immer man verwenden möchte, um halt
irgendwie das CSS von der Seite zu erzeugen,
das kann man natürlich machen, aber wie man das
jetzt macht und der Umgang damit, das ist natürlich wieder
irgendwie so eine eigene Geschichte.
Das ganze JavaScript,
also der Teil der Web-Applikation, die halt auf dem
Browser läuft, ist nochmal eine andere Geschichte, die wird dann
halt auch vielleicht, die wird wahrscheinlich nicht
mal von Django ausgeliefert, sondern von dem statischen
Web-Server, der halt irgendwie vor Django meistens
noch davor ist und irgendwie so
Reverse-Proxy vor der Applikation ist,
für statische Inhalte und Dinge.
Und
ja,
Typografie,
überhaupt wie
SSL, dann die ganzen
Netz, also da ist noch so viel Zeugs mit
dabei, der halt auch eine Rolle spielt,
wenn man jetzt so eine Webseite betreibt,
der jetzt nicht unbedingt
Teil von Django ist, da gibt es noch
viel zu tun und das ist natürlich so ein Ding,
also wenn man jetzt einfach nur Django
macht, dann hat man damit die
Komplexität dieses Gesamtdings
irgendwie eine Webseite betreiben
noch nicht komplett abgedeckt.
Also es ist ein ganz guter Teil davon, aber
da gibt es halt...
Machen wir dazu tatsächlich nochmal eine Folge, also wie man eine Webseite
komplett betreibt, so von Server und
Deployment und wie man so, weiß ich nicht,
Load Balance macht oder sowas.
Könnte man auf jeden Fall auch. Hat dann nicht mehr
so wahnsinnig viel mit Python zu tun.
Unter Umständen... Gibt es das nicht in Python?
Doch, man kann das auch alles in Python machen, aber ich mache
das auch in Python.
Nee, viele Bereiche
gehen ja dann raus, auch aus der
eigentlichen Programmierung und gehen dann in die
Administration rein und da ist Python natürlich
ein wichtiges Werkzeug, aber
jetzt nicht das, worauf es läuft.
Ja, also dann
vielen Dank euch beiden hier, dass ihr
so schön euch unterhalten habt,
mir ein paar Fragen beantwortet habt, die ich so hatte.
Ich glaube, so viel zusammenfassen
müssen wir gar nicht. Wir haben so ein bisschen Dango gemacht heute.
Ja, das war
super und wir haben
heute noch gar nicht über Events gesprochen, aber ich kenne gerade
keine, die jetzt in nächster Zeit
sind, so jetzt am Jahresende.
Ich weiß nicht, ob euch welche
einfallen? 12. Dezember
ist Treffen der
Python User Group
Köln, PyCologne.
Ja, jede Woche ist halt
irgendwie Python-Fu in Düsseldorf.
Nächstes PyTDF-Treffen ist erst
wieder am 9. Januar, glaube ich. Also
Treffen der Düsseldorfer Python User Group.
Falls ihr eure eigene E-Mail
promoten wollt, schreibt uns bitte bitte eine E-Mail.
Ja, natürlich. Also ich meine, wir kennen
jetzt nur die Sachen im Rheinland,
Düsseldorf, Köln-Umfeld.
Ja, würde ich sagen.
Vielen Dank, schön, dass ihr zugehört habt.
Noch einen schönen Tag, Morgen, Abend,
wo auch immer ihr gerade seid, was ihr macht.
Und ja, bis zum nächsten Mal.
Bis zum nächsten Mal. Tschüss.