Transkript: PP02 - Django

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

Wir haben heute 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 regen wir gemeinsam hin.

Versuchen auch eine Einführung dazu zu machen.

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

Sagt uns auch nochmal Hallo, ihr zwei.

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

Und genau, zum Django-Thema haben wir 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 du sich 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 Python Club in Chaos Computer Club in Düsseldorf in der Python-Ecke.

Und haben dann festgestellt, dass wir beide Django machen und arbeiten eigentlich seither zusammen.

Beim Python Food an Donnerstag.

Genau, jeden Donnerstag ab 18 Uhr.

Ja, der Veranstaltungsschutz kommt erst at the end, but we versuchen das ab und zu noch mal ein bisschen einzustreuen.

Yeah, um weiter heute Django.

Deswegen fangen wir vielleicht nochmal an.

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

It's nice so an alter Haser wie der Jochen.

What is it überhaupt?

Django hört sich jetzt erstmal an ja.

Was ist das?

Tanz?

It is benannted by Jazz Gitarristen, Django Reinhardt.

The 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 Webanwendungen 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 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 wie Snakes and Rubies.

Um sehr zu empfehlen auch übrigens.

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

Der Captain Moss war das, glaube ich, der Dame.

Und der von Ruby Rails heißt David Heinmeier-Hanson.

Und die beiden haben so in usually Ansatz.

And haben eben Snakes and Ruby's.

And the one, the Caplan Moss had each other, where many problems with Django used.

So I'm quite the Querschnitt.

We have a message URLs to define and then a functionality to define, and then the templates that are and something on the data bank to hold.

Wodurch unterscheidet sich the Ruby on Rails art and we are from the world.

Also ein Beispiele is wie eben URLs funktionieren.

In Django definierst du eine URL, in dem du einen regulären Ausdruck entschuldigst.

And when the regular Ausdruck entspricht, what the benutzer in seinem Browser gibst, then the entsprechend funktion dazu ausgeführt.

In Ruby and Rails is this and Ruby and Rails is this during a convention, you have a controller that a name has, and over these name will automatically the URL, with what you dies in controller entsprechen kannst.

That he has auf der einen Seite stärkere Conventionen, you have damit the Möglichkeit, ein Ruby on Rails Projekt, sag ich mal, schneller zu verstehen, weil they all the gleich struktur have.

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 und Rails wesentlich schneller Ergebnisse sieht.

Ich muss nur diesen Controller schreiben und ich muss eben 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 nochmal von Controllern geredet, vielleicht weiß jetzt noch nicht jeder Hörer, was das genau ist.

Wollt ihr das nochmal kurz erklären?

Ich weiß nicht, Jochen hat 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, 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 kann sich halt auch vorstellen, dass ein anderes Interface nur textbasiert ist, wo sich dann Leute quasi Patellnet 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 Modellen zu holen, die dann in der Form den Views zu geben, die sie das halt brauchen.

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

Also ein 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 bisschen.

Also die Klassen gibt man Benutzerverwaltung 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, weiß nicht, ein bisschen.

Hier sind ja alle ein bisschen verwirrend durcheinander.

Da stolpert den 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, dass das geht halt nicht mehr so an.

Haben das ja an die anderen Leute auch dran gewöhnt, wie das dann heißt.

Ja, verstehe ich.

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

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

Und die Breite ist da, 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 her.

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 Grundfunktionalität ist eben sehr schnell damit umzusetzen.

Auf was konzentrierst du dich dann besonders in diesem Kurs?

Also auf das Model, das Hue, das Controller-Ding?

Nee, die müssen alle drei zusammenarbeiten, weil du mit jedem dieser Teile allein kannst du nicht, 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 drü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 dann eine Webseite daraus werden soll.

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

Und ich brauch irgendwas, was eine Funktionalität darstellt, weil sonst macht meine Webanwendung nichts.

Und das ist hier in Django eben der Controller bzw.

die View-Funktion.

Und 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 oder eine Seite der Admin.

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

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.

And this is eine sehr schöne Sache, wenn man eben so eine Anwendung zum ersten Mal schreibt and 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.

And 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 hinzu verschieben 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 Datenbankdingen 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 gibt, weiß ich nicht, von Flask oder von Pyramid mal gehört, auch so?

Nee, also 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, die man sonst wo 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 ja auch den Django ORM nehmen.

Man könnte auch den Django, genau.

OR was?

ORM Object Relational Mapper.

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

Okay, jetzt

habe ich das verstanden.

Ja.

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

Während bei Django kann man das theoretisch auch.

Mit manchen Dingen ist es einfacher als mit anderen.

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

Also so 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 besserer 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 sich jetzt irgendwie immer neu zusammenstöpseln muss.

Wie ist das denn zum Beispiel, wenn ihr jetzt so ein Modul benutzt, was es irgendwie schon gibt, wie viel Arbeit wäre das denn jetzt, in so ein neues Framework zu integrieren?

Das kommt total auf das Modul an.

Diese Fragen kann man so eigentlich nicht beantworten.

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

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

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

Und Django is mehr so ein bisschen, here we have dir einen Bausatz gemacht und du kannst gerne drauf aufbauen, aber die müssen so funktionieren, wie wir das vorgegeben haben.

Das heißt eben, wenn ich irgendein Modul habe oder eine Bibliothek, die nicht integriert ist, dann bin ich in Flask sicherlich schneller damit unterwegs, weil ich dann eben sowieso für diese Anbindung sorgen muss.

In Django ist es dann eben oft so, dass es schon eine Django-Variante gibt davon, die mir eben genau diese Integration schon gibt.

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

Heißt halt aber, dass ich darauf angewiesen bin, dass schon jemand die Arbeit gemacht hat und auch fortlaufend tut, weil die Versionen natürlich ständig aktualisiert werden.

Und es hat alles

so seine Vor- und Nachteile.

Wie würdet ihr denn einsteigen, wenn ihr jetzt irgendwie jemanden habt, der das noch nie gemacht hat?

Möchtet ihr seine erste Website, einen Blog einstellen, das würdet ihr ihm empfehlen?

Einfach das Paket installieren und Tutorial lesen oder gibt es das 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.111 und wir sind jetzt aber auch eigentlich schon bei 2.1.

Da kommt dann wahrscheinlich für die nächste stabile oder lang, 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 Aninstieg in Django über dieses Buch gefunden.

Das war irgendwann 2013 oder so, weil ich irgendwie in einem Projekt plötzlich mit einem Django-Backend konfrontiert war und dann, ja, mir auch gesagt wurde, dann liest doch mal einfach dieses Buch und dann macht alles Sinn plötzlich.

Und so ein bisschen war das schon so.

Also das war 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 Krusen.

Oder Textbook.

Nee, ich mach 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 ist schon, es hat schon zu viel Flavor.

Es ist schon zu viel, zu weit von dem Vanilla Django weg von dem Discord.

Das sind ja noch mehr Freiheiten, die du selber gerne kreativ ausleben würdest, wenn du genau verstanden hättest, wie es funktioniert.

Genau, and das bedeutet auch, dass man eben auf diese Wahl festgelegt ist, die die Leute von ToScoops 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

machen möchte.

Das müssen wir vielleicht gleich nochmal kurz erklären, was ein Docker-Container ist und was eine CRISPR-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 den Django-Entwickler.

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, is meine Empfehlung immer erstmal einen Schritt zurück zu gehen 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 an ein Projekt ausdenken, was sie 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.

Mach 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 in den Texteditor rein.

Wenn ich die Wachsmalstifte von meinem Kleiding 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 ich es ein Blog sein, was YouTube-Videos anzeigt, oder soll es ein Podcast-Blog sein?

Or a Blog sein, where I don't know, my texture, there are builder remains, yeah, or no.

Loud of the things that for this product entered, and they actually in this project, but when we argue, not so much.

And this is for me a wicked thing, that I know where I hit.

Then muss man.

But man will trot where man möchte.

Is it sinnvoll, so from 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 genau, also ein Problem bei Django ist halt, da ist schon relativ viel Funktionalität enthält und viele Teile und man möglicherweise für ein System, was dann hinterher irgendwas tun soll, wie einen Block implementieren oder so, noch viel mehr Kram braucht.

Da braucht man halt möglicherweise noch eine Anbindung an ein Cache-Backend, eine Redis oder sowas, man Cache die, braucht vielleicht irgendwie eine Volltext-Suchmaschine, die man dann noch mit 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 Block schreiben wollte und mal schnell irgendwie eine Django hochziehen wollte.

Und da gibt es dann halt so ein Tool, nennt sich Cookie Cutter, das ist auch von den Autoren von Two Scoops auf Django oder beziehungsweise von einer der beiden Autoren und das legt dann halt so ein Projekt quasi an.

Da werden am Anfang im Grunde genauso ein paar dieser Fragen gestellt, halt so möchtest du Docker oder lieber nicht oder brauchst du eigentlich Hintergrundtasks 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 dann 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, die man auch nur noch schwer ändern kann und man versteht nicht so genau, was da passiert.

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

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 Hutter 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 das 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 hab, 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.

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 da muss man wieder eine ganze Menge von Hand ändern, was man ja eigentlich vermeiden wollte, indem man Cookie Cutter verwendet, daher.

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 nicht so toll findet, dann hilft es einem halt nicht.

Dann muss man vielleicht ein eigenes Template machen oder so.

Viele Sachen, die in dem Cookie-Cutter-Template drin sind, gehen für mich so ein bisschen in Richtung Produktivbetrieb.

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, vom 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?

Also meine Blogs haben nie so viele gehabt.

Vielleicht habt ihr mehr Erfolg als ich, ich wünsche es euch.

Aber es ist sicherlich nicht die erste Ausrichtung.

Es wird sicherlich nicht das erste Problem sein, dafür zu sorgen, dass das die ganze Welt gleichzeitig lesen kann.

Sondern das erste Problem wird sicherlich sein, dafür zu sorgen, dass es irgendjemand lesen kann.

Und das überhaupt läuft, vielleicht.

Genau, dass es überhaupt läuft.

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 Lieblings-Template?

Also wenn ihr jetzt das schon irgendwo einsetzt in Produktivbetrieb oder.

Das ist eine schwere Frage, weil da oft sehr viele Sachen zusammenkommen.

Weil man oft sehr, sehr viele Bibliotheken reinlädt, die alle nur einen kleinen Teil machen.

Das ist so, wenn ich die Frage, welches Lego-Teil ist denn dein Lieblings-Lego-Teil?

Ritterburg.

Ja, aber das ist ja kein einzelnes Teil.

Das sind ja gleich hier was sehr Großes zusammengegeben.

Also viele kleine Steine dabei, glaube ich, ja.

Genau, und die einzelnen Steine an sich sind alle nicht super interessant, aber wenn man sie dann sowas zusammengebaut hat, dann ist das, was man gebaut hat, super interessant.

Okay, aber gut, aber du weißt ja dann schon, welche Steine du dann brauchst, damit du dann irgendwie sowas gießen kannst.

Ja, klar.

Also das heißt, man hat sich schon so einen Workflow, an dem man sich dann gewohnt und er ist dann auch irgendwie individuell.

Ja, okay.

Ja, aber auch da, also ich, 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 jemand auf gekommen ist, wo sagt so, hey, denk doch mal drüber nach, das wäre ein toller Tipp.

Macht das doch mal diesen Weg oder.

Ja, also wenn ich da quasi eine App nennen sollte, wäre das wahrscheinlich Django Image Kit tatsächlich.

Django Image Kit.

Ich habe da mal so einen 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 responsive 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 noch irgendwie backendseitig hinbekommen.

Also es muss halt die Bilder in unterschiedlichen Größen geben, man muss halt irgendwie die entsprechenden Text 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 waren 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 Image-Kit über den Weg, das 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 so ein bisschen hässlich und ich wusste auch, dass es alles nicht schön war.

Und das hat das halt komplett ersetzt.

So, ich musste es nur noch importieren und habe dann irgendwie da so meine Spec-Dinger an die an die Images rangeschrieben, sozusagen, welchen Größen ich das haben möchte.

Und dann war es das.

Voll gut.

Also hat dieses Problem irgendwie für mich mehr oder weniger erledigt und das fand ich sehr hilfreich.

Und daher denke ich, das ist etwas, was andere auch interessieren könnte.

Weil den Fall, dass Bilder, dass man Bilder ausliefern will auf einer Webseite, den hat man ja doch relativ oft.

Klingt nach tollen Geheimtipps tatsächlich.

Also genau.

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, dass man als Anfänger irgendwo drüber stolpert und gar nicht weiß, wo man anfangen soll und das ist so viel, da kriegt man doch gar nicht mit, was ist jetzt wichtig und was nicht.

Aber ja, gerade für so responsive Implementation, glaube ich, ist das ein super Tipp.

Ich glaube nicht nur, glaube ich, nicht nur als Anfänger so, weil das ist total das gute Beispiel, was der Jochen jetzt bringt, weil ich habe Django ImageKit noch nie benutzt.

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.

Ich muss das kurz in die Shownutzes notieren.

Der hat auch schon eine Bildverarbeitung.

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

Also es ist quasi ein Framework, was nochmal oberhalb von Django ist, was noch mehr Sachen mitbringt.

Und der hat eben auch gleich dieses Bildproblem mitgelöst und deshalb nutze ich das immer gleich für meine Bilder auch.

Ein Wagtail, okay, okay.

Kommt von einem Universum ins nächste, ich glaube, da kann man Bücher, Wochen, Kurse mitfüllen.

Also das war wirklich sehr interessant.

Ja, wobei ich mich jetzt also auch interessieren würde, wie hat Wagtail das Problem dann gelöst?

Kann man, 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 oder.

Das kannst du alles einstellen.

Ah, okay.

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

Um 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, bau 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 Ragtail-Admin, der diese Felder eben, der diese Seiten eben inspiziert und mit reinnimmt und kriegst dann automatisch eben so eine Baumstruktur mit Revisionen und Freigabeprozess und eben Medienverwaltung auch mit dazu.

Und die Medienverwaltung ist relativ flexibel, es gibt so Default-Dinger, die eingestellt sind.

Standardmäßig ist eingestellt, dass die Bilder beim Zugriff erstellt werden und dann gecached werden.

Das heißt, wenn du einmal dieses Bild in einer bestimmten Größe angefordert hast, dann ist es für immer sozusagen da und wird nicht nochmal neu erzeugt.

Das heißt, das ist so ein bisschen die Mitte zwischen den beiden Extremen.

Immer alles sofort anlegen und immer alles neu berechnen.

Das wird berechnet, wenn es zum ersten Mal angefordert wird und dann wird es abgelegt.

Eine Funktion, die mich ungeheuer beeindruckt hat, die sie einfach mal so eingebaut hatten, ist Content-Aware Resize.

Es ist so ein bisschen magisch und man muss das ein kleines bisschen freischalten.

Aber wenn man es einmal eingestellt hat, dann heißt das, 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 oder kleiner gemacht, sondern er zoomt dann quasi auf diesen Bereich rein.

Das heißt, wenn ich ein Bild habe, wo a person drauf is, dann wird auf the gist der Person verkleinert.

And this, I have this iron mal in so a forstelling game from Features in Wagtail, and this is so magic.

They have this flag angema, and then plotly take them not a verkleinerte Version of iron, or where the render abgeschnitten werden, but they zoomed tatsächlich auf die interessanten Bereiche rein.

And that 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, but it is also a bit furchterregend, weil man eben ganz viele 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.

Okay.

Ja, ich weiß jetzt natürlich nicht, wie dieses Feature technisch umgesetzt ist, aber genau.

Da gibt es halt quasi in HTML5 so ein so ein, da gibt es das Picture-Element und das kann halt im Grunde, die nennen das da Art Direction, sozusagen, dass man angeben kann, welcher Bildbereich beim Verkleinern sichtbar bleiben soll und so.

Und wenn Wagtail das so benutzt, dann wäre das natürlich sehr cool.

Es konnte natürlich auch einfach das Bild irgendwie umrechnen oder so und das wäre halt alles so, das kommt halt drauf 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 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 Horset.

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, äh, genau, wenn das automatisch passiert, dann ist er halt immer die Gefahr, dass dann Dinge, Dinge hinterher zu sehen sind, die gar nicht so, wo niemand, ja, wenn er das manuell getan hätte, das ausgewählt hatte.

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

Du hattest eben gesagt, dass es Probleme machen könnte, so viele Module in einen Dango zu packen, die man gar nicht möchte.

Hat was dann Sicherheitsbedenken, die du dann da bekommst?

Ja, 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, aber man muss dann schon die verborgenen Features benutzen, that actually not.

And this is in Django directly with so much, ein Ruhe SQL daraus zu finden.

A normaler Entwickler wird niemals dieses Problem haben, da eine SQL-Injection in Django zu haben.

It is more so eine 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 WagTile und Django Image Kit 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.

Das ist sicherlich von außen nicht sichtbar.

Wenn die Anwendung dann fertig ist oder wenn die irgendwie mal benutzt wird, wird der Benutzer das sicherlich nicht sehen können, dass wir da diese Probleme 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 Third-Party-App oder so.

Und im anderen Teil ist man von was anderem abhängig, dann hat man plötzlich Schwierigkeiten zu updaten.

Das macht halt die Entwicklungsgeschwindigkeit langsam, wenn man sich quasi so unnötigerweise viele Abhängigkeiten nach außen reinholt.

Während wenn man das halt sinnvoll beschränkt, dann kommt man halt eigentlich immer ganz gut halt auch mit Updates klar.

Wenn ich denn 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 wusste 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.

Du kannst mir so eine kleine Scorecard bauen, also was ist jetzt für meinen Nutzen vielleicht das empfohlenste Paket.

Genau, beziehungsweise man sieht dann einfach erstmal, was es gibt überhaupt.

Das ist schon, 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 sich es 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 es Software je fertig?

Und jede neue Version von Django bietet natürlich auch Möglichkeiten, Dinge wieder neu oder anders oder einfacher zu machen.

Und dann eigentlich wahrscheinlich nicht immer, aber ab und zu muss man halt doch mal was anfassen und wenn man nichts mehr anfassen muss, dann ja, eben ist das eher ein Zeichen dafür, dass es nicht mehr richtig maintained wird.

Und ja, Django Packages wird übrigens von einem der beiden Autoren.

Du scopst aufs Django betrieben, dem, der auch Crispy Forms geschrieben hat, was erklärt, warum es die Präferenz ist.

Ja, also die machen da ganz viel.

Und ja, Django Packages ist tatsächlich eine große Hilfe.

Aber ja, so oft ist es auch schwer zu erkennen.

Also ich finde das oft nicht so einfach, wenn man jetzt irgendwie ein Problem hat, das man gelöst haben möchte.

Und man jetzt hat 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 selbst wenn man dann mal zwei, drei reingeguckt hat, dann ist das nicht so einfach zu sagen.

Und dann, ja, manchmal muss man halt dann Glück haben oder irgendwie sich später nochmal umentscheiden.

Aber das ist tatsächlich ein großes Problem.

Also wie wählt man die Software aus, von der man abhängig sein möchte?

Das ist

und jeder baut so mit der Zeit seine eigenen Vorlieben und seine eigenen Präferenzen auf.

Die sind schwer austauschbar.

Es ist super interessant, sich darüber zu erhalten, 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 in so einer absoluten, 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.

Ja, doch, 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 du Sessions gar nicht benutzt, hast du ja immer ein Session-Cookie.

Also müsstest du eigentlich immer das Modul direkt einschalten.

Muss dann die Cookie-Warnung tatsächlich auch bei Sessions, ich dachte nur, wenn man tatsächlich ein persistentes Cookie setzt im Browser.

Soweit ich weiß,

muss man es immer, wenn du Informationen über den Benutzer speicherst.

Und das tust du ja in dem Moment.

Ah, okay, ja, da 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 das 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-Marnung gesehen, da stand einfach nur drin, wir müssen sie informieren, dass wir Cookies setzen.

Das haben wir hiermit getan.

Ja.

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

Ja, aber.

Mir fällt das schwer, das zu verstehen manchmal, was da bestimmte Regulierungen irgendwie eigentlich nutzen sollen.

Und Leuten, die da noch weniger an zum Beispiel EU-Verordnungen dran sitzen in den USA, denen fällt das möglicherweise noch schwerer und dann kriegt man teilweise so fast schon passiv-aggressiv anmutende Geschichten.

So, willst du die Seite wirklich weiter benutzen?

Dann drück jetzt die Meldung.

Ja.

Naja, gut.

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

geregelt wird.

Und dann haben die Leute, die das nicht verstehen, irgendwann ausgedient und dann kommen Leute, die es ein bisschen besser verstehen.

Die sagen dann, äh, mach den Schrott weg oder so.

Hoffentlich.

Man weiß es nicht, kann natürlich immer alles schlimmer werden, aber ich glaube mir mal, dass gute Menschen, ja.

Ja, das ist ja immer Politik irgendwie zwei Schritte vor, drei zurück.

Nein, warte mal, drei Frohe hat zwei zurück, hoffentlich.

Oder im Kreis kann man auch mal sagen.

Ja, ja.

Was habt ihr Neuigkeiten für Django?

Ist euch da was eingefallen, was in letzter Zeit da zukam, wo ihr sagt hast, 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.

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

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 Kurimech drei Jahre

Sicherheitsupdates haben.

Und das heißt, dass es ab jetzt regelmäßig neue Major-Versionen gibt, weil die eben dieses Namensschema angestellt 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 zu 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 der Sprung von 1.11, was die letzte, was die gerade aktive LTS-Version ist, auch 2.0, da waren schon einige Sachen drin, die sich deutlich geändert haben.

Das, was sicherlich, oder was für mich am offensichtlichsten war, ist der Sprung von URL zu Path, wo sich die Definition der verfügbaren URLs in Django verändert hat.

Früher in dem alten URL-Schema hat man einfach reguläre Ausdrücke angegeben.

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, zwischen diesem, an dieser Stelle soll jetzt ein Integer stehen und dem 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 das mit den regulären, 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 einem halben Tag reingefuxt hat, dann sieht das für einen auch alles ganz natürlich aus.

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, wenn ich mir das nie mehr, 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 dann 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 Pars-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 Pars oder so.

Man kann sich selber welche schreiben.

Man kann sich selber welche schreiben.

Oh, das ist ja super.

Das wusste ich jetzt zum Beispiel auch nicht.

Ist ja voll gut.

Ja, man kann sich selber welche schreiben.

Es gibt verschiedene Möglichkeiten.

Du kannst entweder direkt reguläre Ausdrücke machen, also wenn du halt irgendwas ganz Bestimmtes matchen 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-Dinge hintereinander mit, keine Ahnung, 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 muss man 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.

Also das war auf, 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 Kommunikation mit dem Client mit in Django reinnehmen kann.

Aber das geht jetzt auch schon seit einiger Zeit irgendwie sind in neueren HTTP-Versionen, dass man quasi auch über Websockets wieder mit dem Client vom Server aus zurück sprechen 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 Webserver und Applikation.

WSGI, Whisky-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 gibt es ja immer noch.

Es gibt immer noch, ja.

Und da war ja irgendwie schon mal irgendwie quasi sozusagen angedacht, das 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 drei, ich habe keine Ahnung, aber ja.

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 nicht mehr in dieses klassische Webschema 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.

Weil der, 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.

Haben sie sich einen neuen Standard mehr oder weniger ausgedacht, ASGI.

Was dann halt auch neue Server-Backends so fordert.

Daphne heißt der Server.

Genau, genau.

Man kann nicht einfach irgendwie Unicorn nehmen oder den normalen Entwicklungsserver von Django, sondern.

Und da ändert sich dann einiges.

Man kann schon den normalen Entwicklungsserver nehmen, weil der das direkt mitintegriert hat.

Also wenn du Channels installierst,

wenn man es installiert hat, kommt das,

dann kriegst du eine andere Variante von Run-Server und der das automatisch, der automatische Websockets bringt.

Damit du eben in der Entwicklung den Unterschied nicht merkst.

Aber das Arbeiten damit ist deutlich anders, weil du eben diese Kanäle hast und nicht mehr so dieses

Request-Response-Schema hast.

Das muss man jetzt nochmal kurz erklären.

Also ich habe jetzt ganz kurz noch fast nur Wahrheit verstanden.

Request-Response-Schema, ja, Kanäle, hä?

Was ist das?

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.

Error 4.02 Payment Required, ja.

Genau.

Das hat sich dann schnell gezeigt, dass dem nicht so ist und dass man irgendwie einen Zustand braucht und man hat dann eben die Lösung gefunden, dass man Cookies setzt.

Cookies sind im Wesentlichen der Zustand, den du mitlieferst, wenn du eine Webseite anguckst.

Wenn du dich irgendwo einloggst, dann wird eben der Login auf dem Server mit dem Cookie, den du hast, verbunden.

Und jedes Mal, wenn du diese Seite aufrufst, guckt eben der Server, ist das ein Benutzer, der eingeloggt ist oder einer, der nicht eingeloggt ist, und zeigt dann entsprechend die richtige Variante an.

Ist sehr schön, weil man da die Seiten eben so dynamisch generieren kann, dass sie für den Benutzer zugeschnitten sind, der jetzt gerade da ist.

Weil wir ja wissen, wer sich eingeloggt hat.

Oder weil wir vielleicht wissen, was der gestern gekauft hat.

Oder weil wir vielleicht wissen, was der für einen Computer hat oder irgendwie sowas.

Das Schema ist immer noch request response.

The browser sagt, I have this it's bitte give me this it, then macht the server iron was and gives him this it's the art designed.

And the server has a game hinterher to say, oh, hold it's not and vielleicht hat sich da in the time was getan, or vielleicht passiert irgendwas.

So erwartet immer bis der Browser wieder fragt.

Genau, die Verbindung ist dann erstmal weg anderes 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 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 ihr 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's was Neues, gibt's was Neues, gibt es was Neues, gibt's was Neues, sondern du hast nur diese eine Verbindung und die, klar, die wird offen gehalten.

Also insofern hast du eine Ressource belegt.

But this verbinding offenhalten is sowieso was TCP kann und das wird eben über so Keep Alive Mechanismen, die sich dann anpassen, die most wenig Bandbreite verwenden, abgedeckt.

And du hast wirklich nur communication, wenn auch tatsächlich was passiert.

And this gives dir eigentlich zwei Vorteile.

Zum einen sparst du dir die Bandbreite, dass du die ganze Zeit fragen musst, auch wenn nichts passiert ist.

Du weißt ja noch nicht, was passiert ist.

And zum anderen hast du natürlich eine viel schnellere Antwortzeit.

Weil es nicht mehr davon abhängt, wie oft der Client fragt, but when an updates bekommt, sondern wenn ein Update passiert, kann der Server sofort sagen, yes is what passiert.

And the client fragt halt nur all 30 seconds, wenn ich mir meine Chat-Anwendung schreibe, then alle 30 Sekunden, ob jemand was geschrieben hat.

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

Ohne Latenz direkt verfügbar.

Genau, direkt, 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 modernen Anwendungen, ja, 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 that is halt jetzt ein Riesen-Vorteil, ja.

Genau.

Yeah.

Ich glaube, es gab da auch noch Dinge, bevor man das halt mit JavaScript gemacht hat, es waren so solche furchtbaren Dinge wie Long Polling, wo dann der Server immer gesagt hat, ja, nee, 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.

Also es gibt 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, Text, die halt darauf basieren, dass man sowas machen kann.

Also wenn man zum Beispiel in die JavaScript-Welt guckt, da Meteor oder so, die sind halt, das ist halt vom Backend bis zum Frontend darauf ausgerichtet, dass das dem Client irgendwie Dinge schicken kann.

Und damit kann man halt Sachen bauen, die ja, wenn man da sowas zum ersten Mal sieht, relativ verblüffend aussehen, weil sie anders sind als das, was man so von Web-Anwendungen gewohnt ist.

Hast du gerade wieder angegriffen hat, ein Meteor.

Ja, das ist halt so, dieser Stack ist es heute auch nicht mehr so relevant, dass wenn man eine Zeit lang irgendwie halbwegs hip und dass es 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-mäßiges Dings irgendwie weiterreichen und das Ding reicht es halt komplett durch an den Client und du hast halt sozusagen Model View Controller, aber mit dem Client direkt drin und auf dem Client und 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 Desktop-Applikation im Grunde, was die Reaktivität angeht.

Man drückt irgendeinen Knopf und sofort bei jemand anders in einem anderen Browser irgendwie, 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 Sonderlecke und das 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 es jetzt demnächst dann in einer größeren Major-Version kommt.

Ja, ansonsten kann man sich Channels ja auch so reinholen.

Ja, kann man auch, ja.

Also nicht so eigentlich.

Implementiert Django dann Module, die es vorher schon gab, oder hat es komplett eigene Dinge selber?

Sind da vorher so Requests für vorhanden, dass tatsächlich die Entwickler gucken, hey, was ist denn so an Bedarf da oder kommen die mit eigenen kreativen Ideen?

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

Und wie viele

Entwickler gibt es da ungefähr in diesem.

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

Es gibt die Django Software Foundation.

Also die 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 die 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 dieses Projekt am Leben zu halten.

Heißt eben aber auch, dass da inzwischen relativ viel Community Management drin is, weil die Community so gross is, weil es so viele Leute gibt, die Django setzen, that it's notwendig, Prozesse to have.

It is not so centralisiert as we in other projekten violent kennt, sondern it passiert sehr viel einfach aus der Community raus.

Es gibt auch jedes Jahr Conferenzen zu dem Thema.

Es gibt die DjangoCon, die this year in den USA stattfindet.

Es gibt the Django Con Europe, die this year in a station in Europa.

Wo is he next year and what was this year?

This year was it in Heidelberg in Mai.

Yeah.

Next year is in Copenhagen, when I was rich.

And this will be the community organisation.

We community, the benutzer, wollen in the process of weiterentwickling.

And the DjangoCon Europe is for a year in Süd Frankreich, and there had an Insel.

They had a complete Insel gemietet.

This is jedes Mal anders and this is also der Reizer dran.

Warst du da?

In Heidelberg war ich da zum ersten Mal.

War sehr angenehm.

War eben hinter dem, 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 DjungleCon 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.

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

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, 10 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 10 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 Bild-URLs sind.

Das heißt, solange nicht irgendwie ein Content vom Applikationsserver gekommen ist, kann, passiert nichts weiter.

Holt sie nochmal einen Kaffee.

Genau.

Und dummerweise sind halt in diesem kritischen Zeitbereich halt solche Dinge wie halt, dass alle SQL-Statements 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 ja auch eine ähnliche Schnittstelle verwenden wie für Asynchronisierten 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.

Free Do habe ich letztens kennengelernt.

Ja, das ist voll super, aber ja.

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 es zumindest ein Projekt gibt, das versucht, Flask umzubauen, dass es halt alles, also ein I.O.-kompatibel sozusagen ist.

Und bei Django weiß ich jetzt gar nicht, wie weit das ist, oder ob es da überhaupt Beschreibungen gibt.

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

Keine Ahnung.

Ja, wüsste ich jetzt auch nicht, Freihand, aber es hört sich an, als ob du mal ein Enhancement-Proposal einrichten solltest.

Und vielleicht ein Fellowship-Beantragen, dass du auch

irgendwas tun.

Ja.

Tja, tja, tja.

Ist wahrscheinlich auch nicht so einfach, muss man sagen.

Das wäre gut, aber wenn es einfach wäre, dann wäre es ja auch langweilig.

Das ist ja auch schon wahrscheinlich jemand gemacht, 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, also ich habe natürlich auch gedacht, so, okay, wenn ich da jetzt schon irgendwie Django entwickle, dann ist es ja eigentlich, weil es ja jetzt eigentlich schon ziemlich beschämend, irgendwie WordPress zu nehmen, um einen 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 einem Django da schon sehr hilft bei, ist, es gibt so ein Feed Syndication, Feed-App.

Also Django selbst enthält einige Apps, unter anderem halt Admin oder Contrib, also 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, was 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, einem 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 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.

Darf ich jetzt mal so ein bisschen knabbern müssen, aber so einfach nur, dass man dann ein RSS oder Atom-Feed hat, wo die Episoden quasi drinstehen, das war relativ einfach.

Das war auch sowieso bei dem bei dem Blog-Teil war das halt sehr simpel.

Das waren halt irgendwie, keine Ahnung, 15 Zeilen Code oder so und dann gab es ein RSS-Feed zu den Blogposts.

Das heißt, wenn ihr euren eigenen Podcast machen könnt, könnt ihr jetzt demnächst Joch unser Modul dafür verwenden.

Ja, kann man tatsächlich.

Also sagen wir so, das ist halt nicht gut dokumentiert und wahrscheinlich alles irgendwie noch ein bisschen experimentell, aber so benutzen kann man das schon, wenn man ein bisschen furchtlos ist.

Und nicht aufgibt, wenn ich ein bisschen was für Wasser, da muss man schon sagen, ja.

Ja.

Genau, und das ist natürlich auch eine gute Gelegenheit, 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 bin da, ich bin da eigentlich durchaus angetan.

Also auch die Erfahrungen irgendwie mit dem Blockschreiben in Django, das war auch eigentlich alles sehr, sehr nett.

Ja, man kann, man kommt, aber was auch interessant ist, ist halt, es ist 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.

Und das ist halt schon so, also zum Beispiel bei den Bildern wieder, also vielleicht gibt es da auch was oder ich weiß es, 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ß, nichts.

Also es gibt da ja tolle Möglichkeiten.

Es gibt so LibJPEG-Tobo oder Mods JPEG, 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, default-mäß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 doch durchaus was aus.

Oder ich habe mal so einen, ich habe auch einen Bock mit relativ vielen Bildern drin und war dann irgendwie, dachte ich, dann hörte ich immer so Klagen von Leuten, die sich das angeguckt haben, das dauert immer so lange.

Ich habe das gar nicht so gemerkt, gut, ich habe hier irgendwie so 100 M mit, was jetzt auch nicht so furchtbar schnell ist, aber da ging das eigentlich ganz flüssig.

Und dann habe ich halt mal so in den D-D-Bock-Truber geguckt und so und gesehen, so, oh, so die ersten fünf Artikel holen mit vielen Bildern drin, das sind halt so 200 MB.

Wenn man sich das auf dem Handy auf Edge anguckt, dann kann ich mir durchaus vorstellen, dass das ein bisschen langsam ist.

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.

Und ja.

Tja.

Wann das, wo ist dein größter Struggle?

Das ist wie beim Jochen, das sind die Details.

Man kommt sehr schnell so zu den 95% des Projektes, die eigentlich so Smooth sailing sind, die man am ersten Tag durchkriegt.

Und an den letzten 5% arbeitet man dann die nächsten zwei Jahre.

Also es ist schwierig zu sagen, welcher Bereich am schwierigsten ist, weil es eben oft an diesen ganz kleinen Details hängen bleibt.

Also du hast selber für gebaut, was du irgendwo mal offen gestellt hast?

Es gibt so ein paar Sachen, die ich mal gebaut habe und offen gestellt habe.

Genau, 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, hier, ich habe so und so viele Stunden dafür abgerechnet.

Wie wär's, wenn 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 hintergittern werden.

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

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 allem erwartet wird und was man natürlich dann auch gerne macht, weil mehr 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 gut.

Spannend, sehr schön nützlich.

Ja.

Da haben wir doch noch ein bisschen Streichwerb gemacht für die Open-Source-Pakete hier.

Ich bin begeistert.

Ja, für kostenlose Dinge Werbung machen.

Das ist nicht so schlimm.

Ich bin ja auch sehr glaubt.

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.

Der ist jemand wach geworden.

Und wütend.

Naja.

Hoffentlich über Tests sprichst.

Das ist immer sehr schmerzhaft.

Er kommt tatsächlich direkt in die Kreis hoch.

Ja, genau.

Und da gibt es also ich bin da, ich bin ein Fan von PyTest eher als von dem eingebauten Unitest-Framework in Python und da gibt es dann auch diverse Hilfspakete, die einem das erleichtern, irgendwie zum Beispiel PyTest Django oder Pytest Sugar und diverse andere und gibt es noch Dinge, die einem irgendwie so es 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, sehr praktisch.

Also da gibt es halt dann schon eine existierende Integration, da muss man sich gar nicht so selbst umkümmern und das funktioniert eigentlich echt ganz toll.

Also ich weiß nicht, ich glaube, du machst eher Unitest oder das klassische.

Ja, ich benutze eher die in Django eingebauten, also die klassischen Unitests.

Ich mag Py-Test nicht so gerne.

Aber da gibt es doch Methodennamen mit Camel Case.

Ja, muss man nicht.

Muss man nicht?

Nee.

Alles was Testunterstrich heißt, ist ein Test und alles andere ist egal.

Nee, das ist ganz normal.

Dieser Testrunner ist nicht besonders gut.

Ich benutze immer den Nose-Testrunner, aber das ist nur eine Kleinigkeit.

Ja, aber man muss so Dinge machen wie man muss sagen, Assert Equal.

Und da hat man doch auch wieder Camel Case irgendwie.

Ja, das stimmt, diese Assert-Methoden sind so ein bisschen seltsam.

Aber.

Ja, gut.

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.

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 Py-Test heißen mag.

Es ist einfach nur Assert.

Und dann sagt man irgendwie das eine gleichgleich das andere oder so.

Und dann war es auch.

Ja, das kannst du ja bei einem Unitest prinzipiell auch machen.

Ja.

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.

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

Ja, immer neu lernen, Adile heißt ja auch ganz wenig Wissen und immer wieder von neu anfangen und ja.

Ganz, ganz wenig Wissen weiß ich nicht, ob das so eine super Idee ist.

Naja, du kannst immer wieder neue Bausteine suchen und dann.

Ach ja, viele Software, die man so kennt, fühlt sich schon so an, als ob die einfach mit ganz wenig Wissen gestanden sind.

Das stimmt natürlich auch.

Aber was man generell sagen kann, ist also testen, wenn man das nicht macht, das ist eine sehr gute Idee.

Ich habe früher immer gedacht, irgendwie so die ja, 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, das habe ich mich wohlgefü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.

Im Eck geht unangenehm, ja.

Ja, so und seit seit ich irgendwie Tests schreibe, ist das eigentlich nicht mehr so schlimm.

Seit dem

Test ohne passiert

leider immer noch, ja, das ist 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 dran gearbeitet habe, dann habe ich jetzt nicht mehr so ein Problem, irgendwas zu ändern, was die betrifft, weil wenn ich hinterher die Tests durchlaufen lasse und die sehen gut aus, dann kann

ich mir 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 man denkt, das kann eigentlich überhaupt keine Auswirkungen auf irgendwas anderes haben.

Und dann führt man die Tests aus und dann schlagen vier Tests fehl und einer davon schlägt Feld 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 wirklich fieser Bug gewesen.

Und teilweise sind die halt so, dass man sich hinterher auch sagt, also das da kommt man nicht drauf, dass das irgendwie die Auswirkungen hätte, das hätte man jetzt gar nicht, also durch lange Meditation über diese Änderung hätte man das nicht wirklich rausbekommen können.

Wären wahrscheinlich auch gar nicht aufgefallen und dann irgendwann fliegt es dann im, ja.

Wäre es im User aufgefallen oder dann hätte der sich beschwert, was schon ziemlich schlimm ist oder noch schlimmer, es wäre irgendwie eine Sicherheitsdrücke oder so gewesen.

Also es ist, ja, 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 Testfunk nutzen.

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

Wenn ihr so viele Zusendungen kriegt, wie wir das was anderes machen solltest.

Zusendungen übrigens gerne an hallo atpython-podcast.de.

Könnte jederzeit Fragen, Anmerkungen stellen.

Gerade gerade so wunderschon reingepasst.

Also keine Aussage von Johannes?

Ich schreibe meinen Code zuerst und schreibe die Tests hinterher und das schockiert viele Leute.

Ich mach nicht TDD.

I come überhaupt gar nicht klar mit TDD.

TD 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 that these tests erfolgreich werden and nicht mehr.

And the idea dahinter is eben, dass man immer automatisch 100% Test Coverage hat.

Alles what man an Code geschrieben hat, is automatisch getestet.

Weil man den Test vorher geschrieben hat, bevor man den Code hat.

Klingt logisch.

Klingt logisch.

Das Problem für mich ist, dass Tests sind etwas, auch wie der Jochen das so eben beschrieben hat, die fixieren die Funktionalität eines Programms.

Die sorgen dafür, dass ich weiß, das funktioniert genau auf diese Art and 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, when ich noch gar nicht weiß, wie ich es dann tatsächlich machen möchte.

Wie ich denn möchte, dass es am Ende ausschaut.

And deshalb fange ich üblicherweise an Code to schreiben und dann hat man halt irgendwie so ein paar Sachen umgesetzt und dann fange ich an, die Tests dazu zu schreiben.

And then eben sozusagen das so weit aufzubohren that alles drin is, what I have möchte und die Tests.

Was ist denn das Gegenargument?

Wäre das dann, du bist nicht kreativ genug, dir vor die Tests auszudenken, or wäre das dann hinter 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% failesafe ist, aber man kann auf jeden Fall sicher sein, dass die Dinge, die man in die Tests geschrieben hat, funktionieren.

Wie sie funktionieren sollen.

Wie machst du das, Jochen?

Ich muss gestehen, tatsächlich genauso quasi.

Also ja, ich habe mir 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 einem Modul anzuschreiben, wenn ich irgendwas schreibe.

Also quasi in einer Django-App, also 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 irgendwie das installiert hat und dann gibt es halt welche, die man selber schreibt.

Also Userverwaltung ist üblicherweise ein Teil, ne?

Und dann kann halt irgendwie, keine Ahnung, ein bestimmter Teil der Webseite kann halt irgendwie ein anderer Teil sein oder so.

Und ja, üblicherweise schreibt man halt in diesen Apps irgendwas, wenn man jetzt eine Django-Applikation schreibt.

Aber oft, wenn ich nicht weiß, wie ich das, wie ich überhaupt irgendwas machen möchte, dann mache ich nicht das, sondern ich schreibe Sachen in einem Notebook.

Das ist auch dein Hintergrund, der da durchkommt.

Ja, ja, natürlich.

Also ich mache ich mache halt so eigentlich noch mehr als Django so Data Science.

Ein Dupbo, 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 einen Entwicklungsserver, der einen 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 hingehen und mit denen spielen und einfach mal so Sachen so sketch-mäß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, als wenn man.

Oh, Gesundheit.

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 Migration 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 wenn man einfach nur hinkriegen möchte, dass das jetzt oder wie wenn es elegant hinschribt, man weiß oft nicht, wie man das elegant hinschreibt.

Und wenn man Sachen ausprobiert, dafür ist Notebook echt total super.

Kann man halt so lange probieren, bis es geht.

Es muss sich nicht dauernd irgendwie sich darum kümmern, dass man auf der Webseite ist, irgendwas anklickt oder irgendwie den Entwicklungsserver neu startet, weil im Syntax einfach steigt der dann aus und dann muss man irgendwie den neu starten.

Das ist alles so ein bisschen langsam und im Notebook ist das alles viel schneller.

Und dann, wenn es 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 Sweet Spot ist.

Vielleicht ist er dabei noch ein bisschen mehr, vielleicht ist er 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 viele 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, es 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-Admin überhaupt geht.

Überhaupt sollte man nicht unbedingt testen, die halt schon eigene Pakete sind, weil die haben schon Tests und so.

Ja, und für mich ist der Sweet Spot beim Testen eher so bei 70, 80 Prozent und ja, Tests, die man einfach schreiben kann.

Das ist ja auch immer so ein Problem, wenn die Tests zu kompliziert werden.

Also gut, naja, manchmal schaffe ich das nicht.

Manchmal schreibe ich auch Tests, die komplizierte Dinge tun und dann hinterärgere ich mich immer, wenn ich mir, wenn die fehlschlagen und ich dann nicht mehr weiß, was das, was testet das überhaupt?

Warum brauche ich die 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 aber auch so eine Test-Coverage raus?

Also, woher weiß ich denn, wie viel vor meiner Funktion getestet wird?

Zähle ich dann einfach die Funktion, schreib für jede Funktion eine Testfunktion und gucke dann und dividiere dann in Prozenten?

Nee, da gibt es Tools für da gibt es ein Tool, das heißt Coverage.

Kreativer Name und der gibt einem 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 ist da nicht.

Okay, also ganz easy.

Ganz easy.

Das macht einmal eine Ausgabe auf der Kommandozeile, 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, ich habe eine Ansicht des Kurz und sieht dann halt irgendwie farblich markiert, welche Kurzeilen 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 irgendwie UL-Cons oder.

Die Stirn-Methode.

Ja, dann muss man.

Man kriegt nie auf 100% Coverage, wenn man diese Methode nicht testet, aber die ist völlig irrelevant.

Auf der einen Seite, wenn man dann halt durchscrollt und sieht dann halt irgendwie ein komplexes Ding, einen Algorithmus, der irgendwas macht und der ist gar nicht getestet, dann sollte man, da sollte man dann vielleicht nochmal einen Test schreiben.

Und so kann man, so gehe ich jedenfalls vor.

Ich guck mir halt mal an, was die größten Code-Teile, die halt am meisten Funktionalität irgendwie haben.

Wenn die nicht getestet, dann fange ich da halt da an.

Es gibt auch ganz viele IDEs, die das integrieren, wo du quasi diese Ansicht in der Idee hast.

Wenn du eine Testansicht haben kannst, wo du eben siehst, welche Zeilen durchgelaufen sind.

Welche Idee nutzt du?

Ich benutze PyCharm.

Vor ein paar Jahren sind die plötzlich groß geworden.

Jetbrains.

Das ist so eine Variante von einer IDE, die hieß früher Idee.

Die gibt es auch immer noch, aber es ist eine Java-Idee.

It is schwierig, da eine Empfehlung zu given, weil auch da die Forlieben sehr weit.

Genau, and this is a good one.

I think that it's not the best IDE is and I know that it's not billiger.

But I'm just what I can.

The Community

Edition can use, but they have not so good Django integration.

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 Web-Applikation entwickelt, dass sich, 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.

Musste man 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 halt dann damit angefangen.

Ich weiß gar nicht gar nicht, wo die Idee dafür herkommt.

Für den Namen.

Einfach für den Namen nicht und ich weiß auch gar nicht, wo das ist.

Das ist, glaube ich, Vogelmigration, dass die in den Süden ziehen.

Ach so.

Vogelmigration.

Schlau.

Es ist nur ein bisschen schlecht, wenn man danach googeln will.

Ja, ist Django South, kann man schon sagen.

Jedenfalls hat diese Bibliothek 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 Core.

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, man stößt da auf viele Fälle, wo es eklig werden kann und wo man auch für die Migration einen Test schreiben muss und so.

Aber wenn ich mich da an frühere Zeiten zurückerinnere, wo wir ja 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 irgendwie 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 da hat es dann funktioniert.

Da hatte man das Problem, wie synchronisiert man die unterschiedlichen Schemaversionen, was passiert auf einem 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 muss man halt danach gucken, 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 konnektiert sie, hat er dann auch.

Genau, 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 drin liegen, wo man da 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 halt zumindest die Tools an die Hand, mit denen man das in den Griff bekommen kann.

Was halt, wenn man das halt nicht so macht, sondern von Hand oder selbstgestrickt halt doch viele böse Falschstricke für Leute bereithält und die dann also relativ unvorbereitet reinlaufen.

Ja.

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.

Ja.

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 Migrationen mit und die funktionieren auch.

Aber klar, es ist auch so ein Falschstrick.

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, es hat sich auf jeden Fall so.

Ernst könnte man Dango für alles mögliche coole 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 Jungle-Anwendungen, die man vielleicht so man vielleicht so kennt?

Kennst du denn welche?

Ja, zufällig.

Ja, zufällig.

Aber ich kenne bestimmt auch nicht alle, aber zwar, ich glaube, eine der größten Django-Implementationen hat Instagram.

Oder hat Instagram?

Haben sie abgelöst, klar.

Haben sie abgelöst?

Oh je, dann war das jetzt kein gutes Beispiel.

Nee, aber sie sind natürlich sehr groß damit gewachsen.

Das ist natürlich richtig.

Ansonsten.

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

Die betreiben alle ihre eigenen Webserver.

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

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?

Einen von euch.

Es gibt viele kleine Sachen, die damit laufen.

Man sieht es von außen natürlich nicht.

Man sieht eine Web-Anwendung nicht an, ob es in Django geschrieben ist oder nicht.

Äh, ich bin in der Karte.

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.

Ansonsten, also ich weiß, das ist halt auch noch.

Es gibt so eine Zeitung in Amerika.

Ja, genau.

Lawrence.

Das waren die ursprünglichen Entwickler von Django.

Also es kommt aus dem Zeitungsumfeld.

Also auch als Blogplattform für Vertrieb von neuen Newsartikeln oder.

Ja, die haben ihre komplette Zeitungswebseite damit organisiert im Wesentlichen.

Also die, ja.

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 soweit durch?

Tja.

Es gibt noch viele Dinge, die man sagen könnte, aber nichts konkretes.

Ja, dann hatte meine Fragen, wenn wir irgendwie ein Thema nochmal besprechen sollen, dann sagt gerne Bescheid, dann machen wir genau da weiter.

Bestimmt ja auch diese E-Mail-Adresse, indem ihr Fragen

schicken kann.

Ganz genau.

Hallo at python-podcast.de.

Nee, mir fällt da jetzt auch tatsächlich, ja, aber man kann bestimmt auch noch über diverse Bereiche in Django wieder eine eigene Seite machen.

Eigene Episode.

Über Episode über den ORM oder Episode über Template Sprachen oder so.

Ja, oder auch über ganz einfache Sachen wie die Formularintegration oder wie die Session-Integration oder ganz einfache Dinge, die man so für ganz normal hält, die aber

ganz normal, easy und so weiter.

Ja, man kriegt das halt

das halt automatisch mit.

Wenn man Django einmal startet, dann ist es schon da und man muss sich nie Gedanken drü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 ist.

Also wenn man sich jetzt beispielsweise anschaut, wenn man mit X-Code jetzt iOS-Applikationen erstellt oder so, dann ist das halt auch Model View Controller, aber es ist halt eigentlich sehr, 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 jetzt sozusagen nur der Teil der Web-Applikation, die sich jetzt auf einem Applikationsserver befindet und da irgendwie, und der Datenbankteil ist halt jetzt auch noch irgendwie mit drin, sozusagen.

Aber, oder es rendert 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 ein CSS, das ist zwar auch irgendwie ein 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 Netze, 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.

Also wie man eine Webseite komplett betreibt, so von Server und Deployment und wie man so, weiß ich, Load Balance macht oder sowas.

Könnte man auf jeden Fall auch.

Hat dann nicht mehr so wahnsinnig viel mit Python zu tun.

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 euch so schön euch unterhalten habt, mir ein paar Fragen beantwortet, ob ich so hatte.

Ich glaube, so viel zusammenfassen müssen wir gar nicht.

Ich habe 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, PyCologen.

Ja, jede Woche ist halt irgendwie Python Fuhr 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 eigenen E-Mail-Sput verboten wollt, schreibt uns bitte eine E-Mail.

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.