Ja, hallo liebe Hörerinnen und Hörer, willkommen beim Python-Podcast in der heute zweiten Episode.
Wir haben euch da ein ganz besonderes Thema für euch mitgebracht, und zwar Django.
Für das zweite Mal natürlich ist es auch schon ein steiles Thema, aber ich glaube, das kriegen wir gemeinsam hin.
Wir versuchen auch eine Einführung dazu zu machen, fangen heute ein bisschen an, wieder mit den Basics,
und dann gehen wir ein bisschen in die Tiefe des Themas.
Wir sind wieder im wunderschönen Wintergarten hier von Jochen, ich bin der Dominik,
und diesmal habe ich nicht nur den Jochen dabei, sondern auch den Johannes.
Danke auch nochmal, hallo ihr zwei.
Ja, genau, hier ist auch Jochen, hallo von mir.
Und genau, zum Django-Thema haben wir uns direkt schon mal einen ersten Expertengast eingeladen,
und wir hoffen, dass der da irgendwie mehr weiß als wir und uns da viele interessante Geschichten erzählen kann.
Und das ist Johannes, und genau, das kannst du dir vielleicht mal vorstellen.
Ja, hallo, ich bin Johannes.
Und nach der Ankündigung kann ich eigentlich gar nicht mehr so richtig viel sagen.
Jetzt sind die Anforderungen gestellt, und mal schauen, ob ich die erfüllen kann.
Also du arbeitest auch mit Django?
Ich arbeite auch mit Django, genau.
Ich arbeite mit Jochen viel zusammen, der ja auch mit Django sehr viel macht.
Und wir haben uns auch darüber kennengelernt, im Chaos Computer Club in Düsseldorf in der Python-Ecke.
Und haben dann festgestellt, dass wir beide Django machen.
Und ja, arbeiten eigentlich seither zusammen.
Gut, beim Python-Foodern, donnerstags.
Genau, jeden Donnerstagabend ab 18 Uhr.
Ja, also die Veranstaltungen kommen erst am Ende, aber wir versuchen das ab und zu nochmal ein bisschen einzuschreuen.
Nein, super.
Ja, wir machen heute Django, deswegen fangen wir vielleicht nochmal ganz am Anfang an.
Johannes kann, glaube ich, sogar etwas zur Geschichte von Django erzählen.
Er ist nämlich genauso ein alter Hase wie der Jochen.
Wäre doch super, wenn du nochmal kurz erklären könntest, was das ist, wo kommt das denn her, was macht man damit überhaupt.
Und also Django hört sich jetzt erstmal an.
Warte, ist das ein Tanz?
Ja, es ist benannt nach einem Jazz-Gitarristen, Django Reinhardt.
Die beiden Entwickler, die sich das ausgedacht haben, waren wohl Fans von diesem Gitarristen.
Es hat sonst auch keinerlei Verbindung mehr dazu, nur der Name stammt daher.
Django ist ein Framework, um Web-Anwendungen mit Python herstellen zu können.
Da gibt es mehrere solcher Frameworks, aber Django ist da sicherlich das Größte und sicherlich auch das Ausgereifteste.
Das gibt es jetzt schon seit - jetzt müsste man rechnen können - knapp 15 Jahren?
Ja, ich glaube, 2005 ist es rausgekommen oder 2004, ich weiß nicht, ich glaube, kurz nach "Ruby on Rails".
Und ich denke, das war auch so ein bisschen vielleicht das Vorbild für Django.
Ja, ich weiß gar nicht, ob die sich gegenseitig als Vorbild genommen haben, weil die sind ja schon so ein bisschen unterschiedlich in ihren Ansätzen.
Ich habe das damals kennengelernt von einer Veranstaltung wie "Snakes and Rubies", sehr zu empfehlen auch.
Übrigens gibt es auf YouTube immer noch das Video, inzwischen ungeheuer alt, wo sich eben da die beiden Hauptentwickler getroffen haben.
Der Jack of Kaplan Moss war das, glaube ich, der da war und der von "Ruby on Rails" heißt David Hanmeier-Hansen.
Und die beiden haben so im Wesentlichen ihre beiden Ansätze vorgestellt und haben eben "Snakes and Rubies" gezeigt.
Und der eine, der Kaplan Moss, hat eben gezeigt, wie man Probleme mit Django löst.
Den Querschnitt, wir haben eine Möglichkeit, URLs zu definieren und dann eine Funktionalität dazu zu definieren und dann die Templates dazu anzuzeigen und Sachen aus der Datenbank zu holen.
Und dann hat der David Hanmeier-Hansen mehr oder weniger das Gleiche gemacht, aber auf eine ganz andere Art und Weise, eben auf die "Ruby on Rails"-Art und Weise.
Wodurch unterscheidet sich die "Ruby on Rails"-Art und Weise von dem, was wir jetzt suchen?
Ja, zuerst mal natürlich, dass es eine andere Programmiersprache ist.
Ja.
Aber "Ruby on Rails" geht wesentlich mehr über...
Konventionen.
Bei Django wird sehr viel explizit gemacht, also ein paar Beispiele ist, wie eben URLs funktionieren.
In Django definierst du eine URL, indem du einen regulären Ausdruck hinschreibst.
Und wenn der reguläre Ausdruck eben dem entspricht, was der Benutzer in seinem Browser eingibt, dann wird die entsprechende Funktion dazu ausgeführt.
In "Ruby on Rails" ist das anders.
In "Ruby on Rails" ist das durch eine Konvention gemacht.
Du hast einen Controller, der einen bestimmten Namen hat und über diesen Namen wird automatisch die URL bestimmt, über die du diesen
Controller ansprechen kannst.
Das heißt, du hast auf der einen Seite wesentlich stärkere Konventionen, du hast damit die Möglichkeit, ein "Ruby on Rails"-Projekt,
sag ich mal, schneller zu verstehen, weil die alle die gleiche Struktur haben.
Andererseits musst du diese Sachen eben wissen, du musst die Konventionen wissen.
Und das ist für mich so ein bisschen der große Unterschied am Anfang gewesen.
Ich mag es gerne, wenn Sachen explizit dastehen, wenn die Programme das tun, was ich hingeschrieben habe und nicht so ein bisschen magisch hintenrum
das tun, was halt eingerichtet ist, weil das jemand wusste.
Und das ist gleichzeitig eine Stärke und eine Schwäche, weil man eben dadurch in "Ruby on Rails" wesentlich schneller Ergebnisse sieht.
Ich muss nur diesen Controller schreiben und ich muss ihm nur eben eine bestimmte Datei an die richtige Stelle hinlegen und dann wird das automatisch zu einer
kompletten Webseite.
In Django muss ich den ganzen Weg gehen.
Ich muss die URL definieren, ich muss die Funktionalität definieren, ich muss die Datenbankmodelle definieren, ich muss die in die
Datenbank reintun, ich muss die aus der Datenbank wieder rausholen und dann muss ich sie in ein Template reintun, was ich selbst definiert habe.
Du hast gerade nochmal von Controllern geredet.
Vielleicht weiß jetzt noch nicht jeder Hörer, was das genau ist.
Wollt ihr das nochmal kurz erklären?
Ich weiß nicht, Jochen hat es einmal mir schon ganz schön erklärt, worum es dabei geht.
Ja, also das wäre dann halt auch so eine Gemeinsamkeit zwischen "Ruby on Rails" und Django.
Das sind beides so Model-View-Controller-Frameworks, also die diesen Ansatz halt halbwegs sauber irgendwie umsetzen.
Das heißt, es gibt halt Modelle, in denen
irgendwie definiert wird, wie die Daten aussehen, die man jetzt in der Applikation hält.
Also wie der State der Applikation quasi abgelegt ist, sich verhalten soll.
Meistens hat man eine relationale Datenbank irgendwie im Hintergrund und dann muss halt aus den Modellen wird dann halt ein Schema generiert.
Dann werden die Daten halt da irgendwie reingespeichert.
Und dann hat man sogenannte Controller, die quasi die Daten, die in den Modellen sind, mit den Views,
die halt dafür zuständig sind, wie das hinterher aussehen soll, für ein Benutzer-Interface verbinden sollen.
Wobei Benutzer-Interface ganz unterschiedliche Sachen sein können.
Also ein Beispiel ist, man macht irgendwie ein Weltraum-Kampfspiel und dann gibt es halt vielleicht irgendwie ein grafisches Interface,
wo man irgendwie die Raumschiffe rumfliegen sieht und so.
Aber man kann sich halt auch vorstellen, dass ein anderes Interface nur textbasiert ist,
weil wo sich dann Leute quasi per Telnet irgendwie einloggen oder so und das muss dann natürlich unterschiedlich
aussehen, je nachdem, was man für ein Interface hat.
Oder wenn man jetzt ein Touch-Interface hat, ist es nochmal anders.
Und dafür diese Unterschiede abzubilden, ist halt der View zuständig und der Controller.
Die sind halt dafür da, sozusagen die Views mit den Modellen irgendwie zu verbinden, also die Daten irgendwie aus den Modellen zu holen,
die dann in der Form den Views zu geben, die sie deshalb brauchen.
Und ja, das Ganze nennt man irgendwie Model-View-Controller.
Also Modell ist das, was in der Datenbank angelegt ist, wie dann das...
Ja, aber auch die Objekte quasi, die hinterher in der Applikation sich um die Datenhaltung kümmern, sind auch sozusagen die Modelle,
ja.
Okay.
Also Datenbank ist halt eigentlich nochmal ein Problem.
Also die klar ist, man benutzt die Verwaltung von dieser Datenbank auch.
Ja, ja, genau, genau.
Und was ein bisschen verwirrend ist, ist halt, dass in den Django, die die Views Templates heißen und die Controller-Views,
das, weiß nicht, ein bisschen...
Hier sind wir alle ein bisschen verwirrt und durcheinander, okay.
Ja, da stolpern Anfänger oft drüber, dass die Bezeichnungen anders sind und eben ausgerechnet View und View unterschiedliche Dinge bedeuten.
Gemein, da muss doch jemand mal so...
Da muss jemand mal so ein Request stellen und sagen, hey, ändert das mal, oder?
Ja, aber nach über zehn Jahren ist das halt ein bisschen schwer zu ändern.
Ja, das ist halt nicht...
Da haben sich ja die anderen Leute auch dran gewöhnt, wie das dann heißt, ja, verstehe, verstehe.
Ja.
Ja, also wofür nutzt man denn Django, wenn ihr jetzt gesagt habt, was da schon man machen kann?
Mhm.
Ja, im Prinzip kann man jede Web-Anwendung damit herstellen.
Und die Breite ist da, also es gibt quasi keine Begrenzung.
Das ist die erste Anwendung, die sicherlich...
Was sicherlich jeder machen muss, ist ein Blog.
Und jeder Django-Entwickler, der mehr als ein halbes Jahr daran gearbeitet hat, hat auch schon mal einen Blog damit gemacht.
Ja.
Dann gibt es so die ganz typischen Sachen, ein Wiki, Programmieren einfach mal auch zur Übung.
Ich mache regelmäßig Django-Kurse und da programmieren wir dann Shops nach oder eBay nachprogrammiert oder Twitter nachprogrammiert, einfach um zu sehen, wie solche Funktionalitäten in Web-Anwendungen umgesetzt werden.
Ja, also bei einem einwöchigen Kurs ist es absolut kein Problem, eine Basisfunktion von jeder dieser Webseiten hinzukriegen.
Klar, die sehen nicht so schön aus und die haben auch nicht so viele Funktionen wie die tatsächlichen Vorbilder, aber die Grundvorgangsqualität ist eben sehr schnell damit umzusetzen.
Auf was konzentrierst du dich dann besonders in diesem Kurs, also auf das Model, das View, das Controller-Ding?
Ne, die müssen alle drei zusammenarbeiten, weil du mit jedem dieser Teile allein kannst du nicht, hast du keine komplette Anwendung.
Ich habe keine komplette Anwendung, wenn die drei zusammenarbeiten.
Das heißt, man muss so zwischen diesen Bereichen hin und her springen und da gibt es auch verschiedene Möglichkeiten, damit umzugehen, die sich auch, gerade wenn man mit anderen Leuten darüber spricht, zeigen, dass da jeder unterschiedlich damit umgeht.
Aber im Endeffekt geht es darum, diese drei Bereiche zu verheiraten und diese drei Bereiche so zusammenzubringen, dass eine Anwendung daraus wird.
Das heißt, ich brauche irgendwoher Daten, die ich handhaben kann.
Und diese Daten sind eben in den Modellen definiert.
Ich brauche irgendwelche Sachen, die ich anzeigen kann, weil im Endeffekt eine Webseite daraus werden soll.
Das heißt, ich brauche so ein Template oder in der klassischen Sprache, ich brauche einen View.
Und ich brauche irgendwas, was eine Funktionalität darstellt, weil sonst macht meine Web-Anwendung nichts.
Und das ist hier in Django eben der Controller bzw. die View-Funktion.
Nur wenn ich diese drei Teile zusammen habe und wenn die drei Teile so ineinander greifen, dass sie zusammen funktionieren,
daraus eine Web-Anwendung.
Das heißt, der Trick an der ganzen Sache oder der Trick an Django ist eigentlich nicht, dass sie diese drei Dinge gefunden haben
oder diese drei Bereiche geschrieben haben, sondern dass die so integriert sind, dass die nahtlos ineinander greifen.
Klingt praktisch.
Ja, ist es auch.
Eine Stelle, an der man das ganz schnell sieht, ist der Django-Admin.
Das ist eines der am meisten gelobten Module in Django.
Also Django-Admin ist das Backend.
Das ist sozusagen ein genialer Zaubertrick, weil der Django-Admin, das ist einfach ein Modul in Django.
Und ich kann das reinladen, das hat eine URL wie alles andere auch.
Aber was der machen kann, ist, der kann die Modelle, die ich geschrieben habe, inspizieren und mir die dann eben in einer schönen Darstellung zeigen.
Das heißt, ich habe automatisch eine Backend-Funktionalität drin, ich habe automatisch eine Verwaltungsfunktion drin, die aber meine Modellierung nimmt.
Das heißt, die sich auf meine Modellklassen bezieht und die mir das Schreiben von so einer Backend-Funktionalität im Wesentlichen wegnimmt.
Und das ist eine sehr schöne Sache, wenn man eben so eine Anwendung zum ersten Mal schreibt und sagt, okay, ich habe mich jetzt an WordPress orientiert, ich möchte einen Blog machen.
Jeder möchte einen Blog machen am Anfang.
Dann gehört dazu eben auch so ein Interface, wo ich die Blogposts bearbeiten kann.
Und in der ersten Version kann man das sicherlich...
Man kann das sicherlich im Django-Admin einfach drin lassen, weil es da die Möglichkeit gibt, Seiten hinzuzufügen und Seiten zu bearbeiten und Seiten zu löschen und vielleicht Seiten, keine Ahnung, wenn man das modelliert hat, freizugeben oder irgendwo hinzuverschieben oder sonst was zu machen.
Diese ganzen Basisfunktionalitäten, die man immer braucht, die sind im Django-Admin schon drin.
Das heißt oft CRUD, Create, Read, Update, Delete.
Das sind die vier Funktionen, die man immer mit seinem Datenbank-Ding tun muss und die sind eben schon im Django-Admin drin.
Das ist einfach eine sehr praktische Sache, weil diese drei Teile, Model, View und Controller, so gut integriert sind, dass man quasi aus Django heraus die zusätzlichen Dinge da mit reinnehmen kann.
Ist das bei Django ganz individuell oder einzigartig und machen das die anderen Frameworks, die es in Python oder so gibt, von Flask oder von Pyramid mal gehört, auch so?
Ja, gut, es gibt auch noch andere, die das auch so machen, aber ich würde sagen, die Bekannteren, die das halt komplett integrieren, sind eben Django.
Für Python oder halt eben Ruby und Rails für Ruby.
Und wenn man jetzt zum Beispiel Flask nimmt, dann ist das eher ein etwas anderer Ansatz.
Da ist es halt so, dass der Layer, also Flask selber enthält kaum Model-View-Controller-Funktionalität, wie man sonst so in Django hat.
Also es ist halt nicht alles integriert, sondern da kann man sich halt Dinge zusammenstecken, die man benutzen kann.
Zum Beispiel der Object-Relational-Mapper.
Also ORM genannt oft, ist halt in Flask meistens SQL-Alchemy.
Man kann aber auch irgendwas anderes nehmen.
Man kann, wie heißt dieses Dings, Pony oder so, was da irgendwie heute recht beliebt ist, nehmen oder so.
Man könnte auch den Django-ORM nehmen.
Man könnte auch den Django, genau.
OR was?
ORM Object-Relational-Mapper.
Das ist die Verbindung zwischen der SQL-Datenbank, die eben rohes SQL braucht, und der Python-Welt, wo wir ja mit Python-Klassen arbeiten.
Okay, jetzt habe ich das verstanden.
Ja, und genau, bei Flask ist halt der Vorteil, dass man sich da quasi die Dinge, die man vielleicht auch sonst verwendet, oder die man lieber mag, irgendwie benutzen kann.
Während bei Django kann man das theoretisch auch.
Mit manchen Dingen ist es einfacher als mit anderen.
Aber ich würde es jetzt nicht unbedingt gerade empfehlen.
Also den Django-ORM auszutauschen ist halt, ja kann sein, dass das geht, aber das will man wahrscheinlich eher nicht tun.
Wo man das macht, nimmt man dann vielleicht auch besser Flask oder so.
Und ja, das sind halt unterschiedliche Trade-offs.
Das hat halt gewisse Vorteile, wenn alles integriert ist.
Und es hat halt auch gewisse Nachteile.
Es ist halt ein bisschen weniger Flexibilität.
Es ist eine steilere Lernkurve am Anfang.
Aber weil einfach viel mehr Funktionalität da ist, mit der man irgendwie sich vertraut machen muss.
Aber wenn man da erstmal so durchgestiegen ist, dann ist es halt auch schneller, damit irgendwas zu machen.
Oder das halt auf neue Anforderungen anzupassen, als wenn man das jetzt irgendwie immer neu zusammenstöpseln muss.
Wie ist das denn zum Beispiel?
Wenn ihr jetzt so ein Modul benutzt, was es irgendwie schon gibt,
wie viel Arbeit wäre das denn jetzt, in so ein neues Framework zu integrieren?
Das kommt total auf das Modul an.
Diese Fragen kann man so eigentlich nicht beantworten.
Die Mentalität, glaube ich, zwischen diesen Frameworks ist auch so ein bisschen unterschiedlich.
Flask ist so ein bisschen, du kannst alles benutzen, was du willst.
Du musst dann halt selber dafür sorgen, dass die Teile zusammenpassen.
Und Django ist mehr so ein bisschen, hier wir haben den Bowser,
der hat es gemacht und du kannst gerne darauf aufbauen.
Aber die müssen so funktionieren, wie wir das vorgegeben haben.
Das heißt eben, wenn ich irgendein Modul habe oder eine Bibliothek, die nicht integriert ist,
dann bin ich in Flask sicherlich schneller damit unterwegs,
weil ich dann eben sowieso für diese Anbindung sorgen muss.
In Django ist es dann eben oft so, dass es schon eine Django-Variante gibt davon,
die mir eben genau diese Integration schon gibt.
Und dann ist es natürlich leichter, die Django-Variante zu verwenden.
Heißt halt aber, dass ich darauf angewiesen bin,
dass schon jemand die Arbeit gemacht hat und auch fortlaufend tut,
weil die Versionen natürlich ständig aktualisiert werden.
Und es hat alles so seine Vor- und Nachteile.
Wie würdet ihr denn einsteigen, wenn ihr jetzt irgendwie jemanden habt,
der das noch nie gemacht hat?
Möchtet ihr seine erste Website, einen Blog einstellen?
Das würdet ihr ihm empfehlen?
Einfach das Paket installieren und Tutorial lesen?
Oder gibt es da schon eine Best Practice, wo ihr am besten...
Ja, also ich würde, das habe ich bisher dann auch immer so gemacht.
Wenn ich das gefragt worden bin,
das Two Scoops auf Django-Buch zu empfehlen.
Also das ist jetzt halt momentan nicht mehr so richtig super aktuell.
Ich glaube, die letzte Auflage ist für Django 1.11.
Und wir sind jetzt aber auch eigentlich schon bei 2.1.
Da kommt dann wahrscheinlich für die nächste stabile
oder länger supportete Release von Django
wahrscheinlich auch wieder eine neue Version.
Aber da wird eigentlich mal so grob beschrieben,
wie man Dinge tut mit Django und so.
Also ich fand das...
Ich habe damals auch quasi einen Einstieg in Django
über dieses Buch gefunden.
Das war irgendwann 2013 oder so,
weil ich irgendwie in einem Projekt plötzlich
mit einem Django-Backend konfrontiert war.
Und dann, ja, mir auch gesagt wurde,
dann liest doch mal einfach dieses Buch
und dann macht alles Sinn plötzlich.
Und so ein bisschen war das schon so.
Also das war sehr, sehr hilfreich.
Ja, man kann aber auch mit der Dokumentation,
die sehr gut ist, anfangen.
Oder, ich weiß nicht,
vielleicht mit einem von Johannes Grosen.
Oder Facebook.
Ja.
Nee, ich mache das tatsächlich nicht so.
Ich mag dieses Two Scoops of Django-Buch
nicht ungeheuer gerne,
weil das sehr viele eigene Meinungen schon mitbringt.
Und weil man die erst bemerkt,
wenn man sich so ein bisschen mehr damit auskennt.
Ich meine, das ist nicht schlecht, ja.
Und die Leute, die das machen, sind auch Experten.
Und wir benutzen auch sehr viel davon.
Wir werden vielleicht noch über Cookie Cutter sprechen.
Aber ich finde, es hat schon zu viel Flavor.
Es ist schon zu weit von Vanilla Django weg.
Das sind ja noch mehr Freiheiten,
die du selber gerne kreativ ausleben würdest,
wenn du genau verstanden hättest, wie es funktioniert.
Genau.
Und das bedeutet auch,
dass man eben auf diese Wahl festgelegt ist,
die die Leute von Two Scoops of Django schon getroffen haben für uns.
Weil die eben, wie gesagt, ihre Meinungen haben.
Und weil die sagen,
okay, du solltest eigentlich immer diese bestimmten Systeme verwenden
und eben nicht diese anderen.
Ja, genau.
Hast du das schon getan, so ein Beispiel?
Ja, zum Beispiel, wenn die ihre Docker-Container bereitstellen.
Es gibt oft Situationen, wo man eben keine Docker-Container haben möchte.
Das ist halt aber bei denen einfach so.
Die haben alles dockerisiert.
Ist einfach so eine Sache, oder?
Die benutzen Django-Crispy-Forms,
wo ich am Anfang sehr damit zu kämpfen hatte,
weil es gar nicht dem entspricht, wie ich das machen will.
Müssen wir vielleicht gleich nochmal kurz erzählen,
was ein Docker-Container ist und was eine Crispy-Form ist?
Das sind einfach nur so zwei Beispiele,
wo Two Scoops of Django schon was ausgewählt hat,
was man eventuell anders machen würde.
Es ist unwichtig, was das jetzt genau bedeutet
oder was das jetzt genau ist.
Ich fange üblicherweise mit dem Tutorial an auf der Webseite,
weil es zum einen relativ gut geschrieben ist.
Die Django-Dokumentation ist erstklassig,
die ist anwandfrei, die ist super.
Kann ich jedem nur empfehlen.
Auch wenn man nur die Django-Dokumentation liest
und das alles mehrmals angeschaut hat,
dann ist man Experte in Django-Dokumentation.
Und das Tutorial ist einfach ein schneller Einstieg
in was muss ich tun, um eine Funktionalität zu kriegen.
Aber eigentlich würde ich noch einen Schritt vorher anfangen.
Wenn sich jemand da einlesen möchte
oder wenn jemand anfangen möchte, mit Django zu programmieren,
ist meine Empfehlung, immer erstmal einen Schritt zurückzugehen
und zu überlegen, genau was man eigentlich erreichen möchte.
Weil es oft schwierig ist, das gleichzeitig zu machen,
gleichzeitig zu lernen, wie man etwas erreicht
und herauszufinden, was man eigentlich erreichen möchte.
Das heißt, du würdest dir ein Projekt ausdenken,
was derjenige dann umsetzen möchte,
ob es jetzt Freizeit ist oder irgendwie nebenbei
oder schon was Professionelles
und dann direkt an diesem Projekt konkret
sich die Lösungen aus Django dann zu erarbeiten.
Genau, und vielleicht auch einfach mal konkret zu sagen,
was muss ich haben an Funktionalität,
um mein Ziel erreicht zu haben.
Und machst du das dann richtig mit Stift und Papier
oder aus einem Whiteboard
oder malst du da eine Kreidetafel voll?
Je nachdem, wo ich gerade bin
und was gerade für Werkzeuge da sind.
Wenn ich nur einen Texteditor da habe,
dann schreibe ich mir halt ein paar Punkte im Texteditor ein.
Wenn ich die Wachsmalstifte von meinem Kleidung dabei habe,
dann male ich mir was auf die Hand.
Nee, es ist einfach nur wichtig,
ein Bild davon zu haben, was man erreichen möchte.
Zu wissen, wo möchte ich hinkommen.
Soll das ein Blog sein,
was YouTube-Videos anzeigt?
Soll das ein Podcast-Blog sein
oder soll das ein Blog sein,
wo ich nur, keine Ahnung, meine Texte reinschreibe?
Müssen da Bilder rein?
Müssen da andere Dateitypen rein?
Will ich Sharing-Buttons haben?
Lauter so Sachen,
die jeder für sich entscheiden muss,
die jeder für dieses Projekt entscheiden muss
und die sicherlich in jedem Projekt anders sein werden,
die aber eben dazu führen,
dass man während man daran arbeitet,
nicht mehr so viel drüber nachdenken muss.
Und das ist für mich eine ganz wichtige Sache,
dass ich eben weiß, wo ich hin möchte.
Also, das kann sich zwischendurch ja ruhig ändern.
Ja, das kann ja ruhig,
man muss ja seinen Weg auch anpassen können.
Und wenn man sich eben herausstellt,
dass man sich zu viel vorgenommen hat
oder dass das, was man sich vorgenommen hat,
nicht erreichbar ist oder dass es zu schwer ist,
dann muss man das vielleicht anders machen.
Aber man sollte trotzdem immer wissen,
wo man hin möchte.
Weil wenn man, wenn man dann anfängt,
tatsächlich diese Umsetzung zu machen,
ist man so sehr damit beschäftigt,
die Dinge zu lernen, die man wissen muss.
Dass es schwer ist, sich Gedanken darüber zu machen,
ob das überhaupt sinnvoll ist.
Ist es denn sinnvoll, so vom Scratch total anzufangen,
alles selbst zu bauen?
Oder nimmt man dann direkt so etwas
wie ein Template aus einem Cookie-Cutter?
Vielleicht, Jörg, kannst du nochmal kurz erzählen,
was das überhaupt ist?
Ja, also, genau.
Also, ein Problem bei Django ist halt,
da ist schon relativ viel Funktionalität enthält
und viele Teile.
Und man möglicherweise für ein System,
was dann hinterher irgendwas tun soll,
wie ein Block implementieren oder so,
noch viel mehr Kram braucht.
Da braucht man halt,
möglicherweise noch irgendeine Anbindung an ein Cache-Backend,
Redis oder sowas, mein Cache-Di.
Braucht vielleicht irgendwie eine Volltext-Suchmaschine,
die man dann auch noch drin hat.
Man hat vielleicht irgendwelche Background-Tasks,
die laufen müssen und so weiter und so weiter.
Da gibt es noch eine ganze Menge Dinge,
die man halt irgendwie einstellen muss,
wo man Entscheidungen treffen muss.
Und das ist doch relativ überwältigend,
denke ich mal, für jemanden,
der eigentlich nur mal einen Block schreiben wollte
und mal schnell irgendwie eine Django-App,
hochziehen wollte.
Und da gibt es dann halt so ein Tool,
nennt sich Cookie Cutter.
Das ist auch von den Autoren von Two Scoops of Django
oder beziehungsweise von einer der beiden Autoren.
Und das legt dann halt so ein Projekt quasi an.
Da werden einem am Anfang im Grunde
genau so ein paar dieser Fragen gestellt.
So, möchtest du Docker oder lieber nicht?
Oder brauchst du eigentlich Hintergrund-Tasks wirklich?
Und wenn man das angegeben hat,
dann, wenn man das angegeben hat,
dann wird quasi aus den,
wenn halt die Template-Variablen,
die im Projekt-Template drin sind,
ersetzt durch konkrete Werte.
Also man gibt dem Projekt halt einen Namen und so.
Der wird dann relativ oft eingetragen
und dann wird halt so ein Projekt erstellt.
Und das läuft dann halt auch direkt von Anfang an.
Und damit hat man dann ja quasi schon mal
einen großen Schritt geschafft,
weil bis dahin zu kommen,
möglicherweise auf anderem Weg
relativ lange dauern könnte.
Auf der anderen Seite hat man dann natürlich das Problem,
dass man nicht genau weiß,
was passiert ist.
Und man hat jetzt auch viele
sozusagen Einstellungen schon vorgenommen sind,
von denen man jetzt gar nicht genau weiß,
ob man die wirklich so haben wollte oder nicht.
Und ja,
die man auch nur noch schwer ändern kann.
Und man versteht nicht so genau,
was da passiert.
Und das ist natürlich in gewisser Weise so ein Nachteil.
Aber es ist, denke ich,
schon halt irgendwie eine Möglichkeit,
relativ schnell zu einem funktionierenden System zu kommen.
Und ja,
darauf aufbauen kann man dann ja weitermachen.
Aber ja,
es kann einem eine Menge Arbeit ersparen.
Ich mache das meistens so,
wenn ich neue Projekte irgendwie aufmache,
dass ich halt dann irgendwie
das Django-Cookie-Cutter-Template benutze.
Aber ja,
das trifft dann natürlich schon eine ganze Menge Entscheidungen,
die man vielleicht auch anders treffen können wollte.
Klingt aber,
als könnte man es gut gebrauchen für,
sagen wir mal,
Projekte, bei denen man schon relativ genau weiß,
was man will.
Ja.
Naja, also ich meine,
ich habe,
das ist halt dann,
die Frage,
ob man sozusagen
das, was man tun möchte,
den eigenen Bedürfnissen anpasst
oder die eigenen Bedürfnisse halt so,
so ähnlich wie eine SAP-Einführung.
Also quasi,
wenn man sich dafür entscheidet,
das zu verwenden,
dann muss man halt die eigenen Prozesse so umstellen,
dass sie zu SAP passen.
Und dann geht das halbwegs.
Und bei Cookie-Cutter ist es halt auch so,
man muss dann die Dinge so machen,
wie dieses Template das halt irgendwie quasi
vorgibt.
Und wenn man das anders machen will,
hat man,
hat man Schwierigkeiten
oder dann ist es halt nicht mehr so hilfreich,
weil da muss man wieder eine ganze Menge von handen ändern,
was man,
was man ja eigentlich vermeiden wollte,
indem man Cookie-Cutter verwendet.
Daher ist es halt so eine,
also wenn man sich quasi damit abfindet,
dass alles so ist,
wie das in dem Template halt vorgesehen ist,
dann ist es eigentlich ganz nett.
Also dann,
wenn man das nicht so,
nicht so toll findet,
dann hilft es einem halt nicht.
Dann muss man vielleicht ein eigenes Template machen oder so.
Viele Sachen,
die in dem Cookie-Cutter-Template drin sind,
gehen für mich so ein bisschen in Richtung Produktivbetrieb.
Ja.
Die nehmen einem viel Arbeit weg,
wenn man dann Produktivbetrieb hat.
Die haben Sachen drin für Content Delivery,
für Networks
und die haben Sachen drin für Docker
und die haben Sachen drin für Cached
oder für sonst irgendwelche Sachen.
Ich glaube,
wenn man zum ersten Mal so ein Projekt macht,
ist es einfacher,
from scratch einzufangen,
weil man viele von diesen Sachen dann einfach nicht braucht.
Das Blog,
was man da als erstes Mal entwickelt,
wird sicherlich nicht gleich 100.000 Hits pro Minute haben.
Woher willst du das denn wissen?
Also meine Blogs haben nie so viele gehabt.
Vielleicht habt ihr mehr Erfolg als ich.
Ich wünsche es euch.
Aber es ist sicherlich nicht die erste Ausrichtung.
Es wird sicherlich nicht das erste Problem sein,
dafür zu sorgen,
dass das die ganze Welt gleichzeitig lesen kann,
sondern das erste Problem wird sicherlich sein,
dafür zu sorgen,
dass es irgendjemand lesen kann.
Und das überhaupt läuft vielleicht.
dass man überhaupt einen Block hat
und ich glaube dann ist es einfacher mit
dem puren
mit dem Basis Django
umzugehen
Habt ihr ein Lieblingsmodul, ein Lieblingstemplate?
Also wenn ihr das schon einsetzt im Produktivbetrieb
oder
Das ist eine schwere Frage, weil da
oft sehr viele Sachen
zusammenkommen, weil man oft
sehr sehr viele
Bibliotheken reinlädt, die
alle nur einen kleinen Teil machen
Das ist so, wenn ich dich frage, welches
Lego-Teil ist denn dein Lieblings-Lego-Teil?
Ritterburg
Ja, aber das ist ja kein einzelnes Teil
Das ist ja gleich was sehr Großes zusammengebaut
Da sind viele kleine Steine dabei, glaube ich
Genau, und die einzelnen Steine an sich sind alle
nicht super interessant, aber wenn man sie dann
sowas zusammengebaut hat, dann
ist das, was man gebaut hat, super interessant
Okay, aber gut
Du weißt ja dann schon, welche Steine du dann brauchst
damit du dann irgendwie sowas gießen kannst
Ja, klar
Also das heißt, man hat sich schon so ein Workflow, an dem man sich dann gewohnt
und der ist dann auch irgendwie
Okay, individuell
Ja, aber auch da, also ich
jedes Mal, wenn ich
mit Leuten zusammenarbeite, dann
bin ich wieder überrascht davon, wie
unterschiedlich man die Sachen machen kann
Nicht schlechter
oder besser bei irgendjemandem,
aber einfach so unterschiedlich. Auf viele
Sachen, die der Jochen macht, komme ich einfach gar nicht
und das wird sicherlich umgekehrt sein
Genau das fände ich jetzt total interessant, also so Sachen
von euch noch zu hören, wo
sonst niemand auf den Punkt kommt, wo er sagt, hey,
mach mal drüber nach, das wäre ein toller Tipp, mach das doch mal
diesen Weg oder
Ja, also wenn ich da
quasi eine
App nennen sollte, wäre
das wahrscheinlich Django ImageKit
tatsächlich, weil
Django ImageKit?
Ich habe
da mal so einen Blog in Django
geschrieben und
bin relativ bald auf das Problem
gestoßen, dass man, wenn man jetzt so
ja, wir haben 2018
will man schon so irgendwie responsivee
Images haben und dass das halt auch auf dem Handy
irgendwie einigermaßen aussieht, aber man
möchte jetzt auch nicht alle Bilder in riesig groß
ausliefern
wenn man
ja eben auch gerade auf dem Handy
und so
und da muss man ja dann was tun, also da gibt es Unterstützung
in HTML5
durchaus
was solche Probleme
angeht, aber man muss
das ja jetzt auch dann auch irgendwie backend-seitig
hinbekommen, also es muss halt die Bilder in unterschiedlichen
Größen geben, man muss halt irgendwie
die entsprechenden
ja, Tags so rausschreiben,
das halt Source-Set-Attribut
und vielleicht
irgendwie noch andere Geschichten, Picture-Element
so gesetzt sind, wie man das irgendwie haben will
und ich war etwas überrascht,
dass es da in Django quasi überhaupt gar nichts
gibt, also da gibt es zwar
ein Image-Field, aber
das war es auch schon, das kennt dann halt irgendwie so
noch
Höhe und Breite gegenüber dem
File-Field einfach,
wenn man das verwendet, aber das
hat eigentlich nicht viel Funktionalität dafür
sozusagen für diesen
Use-Case, den man oft hat, dass man das Bild
wirklich auf einer Webseite anzeigen will
und
dann habe ich so ein bisschen geguckt und dann gibt es irgendwie so diverse
Thumbnail-Libraries und so
die sind aber alle, die haben halt
diesen Thumbnail-Use-Case
irgendwie, aber nicht, war nicht
so richtig das, was ich irgendwie da gesucht hatte
und dann habe ich dann irgendwie was selber implementiert
und dann irgendwie ein paar
paar Wochen
später oder so lief mir Django ImageKit über
den Weg, dass
quasi, also ich weiß nicht,
das waren schon bei mir so, keine Ahnung,
ein paar hundert Zeilen Python oder so, die ich da geschrieben hatte
und es war alles ein bisschen hässlich
und ich wusste auch, dass das alles nicht schön war
und das hat das halt komplett ersetzt.
Ich musste es nur noch importieren und habe dann irgendwie
meine
Spec-Dinger an die
Images herangeschrieben, sozusagen in welchen Größen
ich das haben möchte und dann war es das.
Voll gut.
Das hat dieses Problem irgendwie
für mich mehr oder weniger erledigt,
und das fand ich
sehr hilfreich und daher denke ich,
dass, ja, das ist etwas,
was andere auch interessieren könnte,
weil den Fall, dass man Bilder
auslebern will auf einer Webseite, den hat man ja doch relativ
oft. Klingt nach tollen Geheimtipps
tatsächlich. Ja, gut, ist jetzt nicht
so ein Geheimtipp, das Ding ist relativ bekannt
und das ist ein bisschen komisch, vielleicht, dass ich es nicht kannte, aber es ist
oft so, dass man... Ja, es ist oft so, dass man als Anfänger
irgendwo drüber schläupert und gar nicht weiß, wo man anfangen soll
und das ist so viel, da kennt man auch gar nicht mit,
was ist jetzt wichtig und was nicht, aber
ja, gerade für so responsive im
Experimentation, glaube ich, ist das ein super Tipp.
Ich glaube, es ist, glaube ich,
nicht nur als Anfänger so, weil
das ist total das gute Beispiel, was der Jochen
jetzt bringt, weil ich habe Django ImageKit noch nie benutzt.
Ah.
Das ist
ein so ein bisschen ein Problem
in der Django-Welt, die ist so groß, dass es
für eigentlich alles was gibt, aber man
muss es erst finden und man muss erst das finden,
was zu einem passt. Ich habe
ImageKit noch nie benutzt, ich benutze Wagtail
und da ist das immer
integriert. Wie heißt das? Ich muss das kurz hier
Shownotes notieren. Der hat auch schon
eine Bildverarbeitung.
Wagtail
ist eigentlich ein Bausatz
für Content-Management-Systemen.
Also es ist quasi ein Framework,
was nochmal oberhalb
von Django ist, was noch mehr Sachen
mitbringt und der hat eben auch gleich
dieses Bildproblem mitgelöst und deshalb
benutze ich das immer gleich für meine Bilder
auch.
Ein Wagtail, okay.
Kommt von einem Universum ins
nächste, ich glaube, da kann man Bücher
Wochen, Kurse mit füllen.
Also das ist wirklich sehr interessant.
Ja, wobei mich jetzt
auch interessieren würde, wie hat
Wagtail das Problem dann
gelöst?
Gibt es da irgendwie Default-Einstellungen, die man machen kann?
Welche Bildgrößen gerechnet werden sollen?
Und wie werden die dann tatsächlich gerechnet?
Ich meine, denn sobald ein Bild hochgeladen wurde,
werden dann die neuen Bilder erstellt oder erst beim
Zugriff und dann gecached?
Das kannst du alles einstellen.
Da gibt es ein Modul, das heißt Wagtail Images.
Um einmal kurz ein bisschen breiter auszutauschen.
Wagtail ist eine Sammlung
von Modulen, die das
Bauen von CMS-Systemen,
also von Content-Management-Systemen
erleichtern sollen. Es gab da schon
was, das heißt Django CMS, das ist relativ
alt, hat auch
mehr so diesen Flask-Ansatz. Hier sind
15 Module, baue sie zusammen, wie du
willst. Wagtail hat mehr so diesen
integrierten Ansatz.
Du musst im Wesentlichen nur noch
sogenannte Seitenmodelle
liefern, also du musst sagen, was
auf einer Seite drauf sein soll.
Für Felder. Und dann
gibt es den Wagtail-Admin, der
diese Felder eben, der diese Seiten
eben inspiziert und mit reinnimmt und
kriegst dann automatisch eben so
eine Baumstruktur mit
Revisionen und Freigabeprozess und
eben Medienverwaltung auch mit dazu.
Und die Medienverwaltung
ist relativ flexibel. Es gibt so Default-Dinger,
die eingestellt sind.
Standardmäßig ist eingestellt,
dass die Bilder beim Zugriff
erstellt werden und dann gecached werden.
Das heißt, wenn du einmal
dieses Bild in einer bestimmten Größe
angefordert hast,
dann ist es für immer
sozusagen da und wird nicht
nochmal neu erzeugt. Das heißt, es ist so ein bisschen
die Mitte zwischen den beiden
Extremen. Immer alles sofort anlegen und
immer alles neu berechnen.
Es wird berechnet, wenn es zum ersten Mal angefordert wird und dann
wird es abgelegt. Eine
Funktion, die mich hier
ungeheuer beeindruckt hat, die sie
einfach mal so eingebaut hatten, ist
Content-Aware-Resize.
Das ist so ein bisschen magisch
und man muss das ein kleines bisschen freischalten.
Aber wenn man
das einmal eingestellt hat, dann heißt
es, dass wenn OpenCV installiert
ist, dann versucht er interessante
Bildbereiche zu finden.
Und wenn ich eine kleinere Version von
dem Bild anfordere, dann wird nicht einfach
der Rand weggeschnitten und das wird nicht einfach kleiner
gemacht, sondern er zoomt dann quasi auf
diesen Bereich rein. Das heißt, wenn ich ein
Bild habe, wo eine
Person drauf ist, dann wird auch das
Gesicht der Person rein
verkleinert.
Ich habe das irgendwann mal in so einer
Vorstellung gesehen von Features in MicTale und
das ist einfach so magisch.
Die haben dieses Flag angemacht und dann plötzlich zeigt
der mir eben nicht kleine
verkleinerte Versionen von irgendwas oder
wo die Ränder dann abgeschnitten werden, sondern der
zoomt tatsächlich auf die interessanten Bereiche ein.
Und dass so etwas
in so eine Bibliothek einfach reinkommen kann,
ist eine total
geniale Sache auf der einen Seite, weil man
eben ganz viele Funktionen da mitkriegt,
aber es ist auch so ein bisschen
furchterregend, weil man eben
ganz viele solche Funktionen drin hat,
von denen man vielleicht gar nicht weiß, dass die da drin
sind oder von denen man vielleicht gar nicht will,
dass die da drin sind. Und das ist so ein
bisschen
schwierig da oft abzuwägen,
will ich sowas in
mein Projekt reinholen oder nicht.
Okay, ja.
Ich weiß jetzt natürlich nicht, wie
dieses Feature technisch umgesetzt ist, aber
da gibt es halt
quasi in HTML5
so ein, da gibt es das Picture Element
und das kann halt im Grunde, die nennen das da
Art Direction, sozusagen, dass man angeben kann, welcher
Bildbereich beim Verkleinern sichtbar bleiben
soll und so. Und wenn
Wagtail das so
benutzt, dann wäre das natürlich sehr cool.
Es könnte natürlich auch einfach das Bild
irgendwie umrechnen oder so und das wäre
halt so, das kommt halt darauf an,
wie das implementiert ist. Und eigentlich würde man
sich ja dann vielleicht auch ein Frontend wünschen,
mit dem man festlegen kann, okay, also dieser Bereich
in dem Bild ist jetzt etwas, was
nicht rausverkleinert werden
soll. Aber da habe ich eben
auch nichts gefunden. Ich habe mir natürlich, also als ich da
irgendwie mein
persönliches Blog irgendwie angefangen
habe zu schreiben, habe ich mir angeguckt, wie sieht das
eigentlich aus, wenn ich jetzt einen WordPress-Blog
aufmache? Was passiert
denn eigentlich da mit den Bildern? Und dann sieht man da so,
ja gut, also die machen das im Grunde, da werden dann halt auch ein paar
Größen vorgerechnet und die werden dann halt mit ausgeliefert
als Source-Set.
Und man hat so ein bisschen, kann man an dem Bild was machen,
man kann irgendwas beschneiden
oder man kann halt irgendwie
quasi
so ein paar Editiergeschichten
machen, aber letztendlich kann
man zum Beispiel was, was dieses Picture-Element kann,
kann man auch in WordPress alles nicht setzen.
Und es gibt eigentlich kaum
Frontends für all die
Möglichkeiten, die man jetzt mit dem Picture-Element hätte.
Und
ja, das ist halt, genau,
wenn das automatisch passiert,
dann ist halt immer die Gefahr, dass dann Dinge
hinterher zu sehen sind, die gar nicht so, wo
niemand, ja, wenn er das manuell getan
hätte, das ausgewählt
hatte. Aber
ja, also die Möglichkeiten sind natürlich schon groß.
Ja.
Du hattest eben gesagt, dass das
Probleme machen könnte, zu viele Module
in einen dann gut zu packen, die man gar nicht
möchte. Gibt es dann Sicherheitsbedenken,
die du dann da bekommst, oder?
Ja, Sicherheitsbedenken habe ich da eigentlich
relativ wenige. Dadurch, dass
da einige Sicherheits-
Standards in Django selbst umgesetzt
sind, sind so diese
ganzen Unsicherheiten, die man so
kennt, die sind da alle direkt
ausgeschlossen. Also es gibt diese
ganz bekannte Sicherheitslücke SQL Injection,
dass man eben die Datenbank dazu bringt,
Code auszuführen, der eigentlich nicht ausgeführt
werden sollte. Und das ist in Django
direkt nur
mit sehr viel Aufwand möglich, muss man so
zu sagen. Man kann es hinkriegen,
dass man so eine Lücke hat, aber man muss ja dann,
man muss dann schon die verborgene
Features benutzen, die es einem
eben ermöglichen, ein hohes SQL
auszuführen. Ein normaler
Entwickler wird niemals dieses Problem
haben, da eine SQL Injection
in Django zu haben. Es ist mehr
so eine, es ist weniger eine Frage
der Sicherheit, es ist eher eine Sache
der Handhabbarkeit.
Komme ich als Entwickler dann noch damit klar,
was ich mir jetzt alles reingeholt habe?
Oder habe ich vielleicht Sachen reingeholt,
die die gleiche Funktion
erfüllen? Habe ich vielleicht Ragtail und
Django ImageKit reingeholt?
Und
dann stehe ich da und habe
zu viele Optionen in der Hand, als dass
ich dann weiterentwickeln könnte.
Oder als dass ich dann sinnvoll
weiterentwickeln könnte,
weil es eben für
jede Sache, die ich machen kann,
eventuell mehrere Optionen gibt.
Das ist sicherlich
von außen nicht sichtbar.
Wenn die Anwendung dann fertig ist oder wenn die
irgendwie mal benutzt wird, wird der Benutzer
das sicherlich nicht sehen können, dass
das
wir da diese Probleme uns reingeholt haben,
indem wir zu viele Module reingeladen haben.
Es ist dann eher was, was die
Entwickler betrifft. Wie können wir jetzt
noch weiterentwickeln, wenn wir drei oder vier verschiedene
Sachen haben, die genau das Gleiche machen?
Ja, und wenn man dann Abhängigkeiten hat, man ist
beispielsweise in einem Teil der Applikation
abhängig von einer bestimmten Version
irgendeiner, von irgendeinem
Django-Party-App
oder so, und im anderen Teil ist man von
was anderem abhängig, dann hat man plötzlich Schwierigkeiten zu updaten.
Das macht halt die
Entwicklungsgeschwindigkeit langsam, wenn
man sich quasi so
unnötigerweise viele Abhängigkeiten
nach außen reinholt, während wenn man das halt
sinnvoll beschränkt, dann kommt
man eigentlich immer ganz gut
halt auch mit Updates klar.
Wenn ich jetzt so eine Auswahl
habe, ich habe jetzt mehrere Optionen,
wen frage ich denn da, welche von diesen Optionen
für mich jetzt die bessere wäre?
Tja, das ist eine sehr gute Frage
und wenn ich die beantworten könnte, dann
wäre auch mein Leben viel
einfacher.
Vieles davon läuft eben über
Gespräche. Man spricht mit den
Leuten in
seinen Python-User-Groups oder in seinen
Django-User-Groups oder auf den Konferenzen
oder mit den Kollegen,
mit denen man vielleicht zusammenarbeitet und jeder wird da
sicherlich Dinge wissen,
von denen man
selbst noch nie gehört hat, egal wie lange man
in dem Business drin ist. Jochen und ich sind
ja jetzt beide schon länger unterwegs und wir können uns sicherlich,
wenn wir uns da einen Abend lang unterhalten,
finden wir beide zehn Sachen, die der andere noch nicht
benutzt hat.
Es gibt eine Webseite, die heißt
Django Packages.
Die versuchen so ein bisschen, das zu sortieren.
Die versuchen so ein bisschen, da diese Themenbereiche
aufzuarbeiten und das
vielleicht auf so ein bisschen eine rationale Ebene
zu ziehen, muss man sozusagen,
wo sie einfach
sagen, okay, was gibt es denn zum Bereich
Bildbearbeitung
und wie stabil ist das und wie viele
Leute benutzen das und
für welche Django-Versionen ist das geeignet
und welche Features hat das, dass man
einfach mal so eine Übersicht
haben kann.
Ja, da kann ich mir so eine kleine Scorecard
bauen, also was ist jetzt für meinen Nutzen
vielleicht, das empfohlendste Paket.
Genau, beziehungsweise man sieht
dann einfach erstmal, was es gibt überhaupt.
Das ist oft einfach eine sehr
große Hilfe, wenn man sieht, okay, es gibt hier 15
verschiedene Bibliotheken, aber zehn davon
sind schon seit Jahren nicht mehr
geupdatet worden. Dann kann ich die gleich
aus der Betrachtung rausziehen.
Vielleicht auch, wenn ich mir die vorher schon
angeguckt hatte und die sehr gut aussahen.
Wenn es keine Updates mehr gibt,
dann ist das oft,
wenn ich mir die vorher schon angeguckt hatte,
ein Zeichen dafür, dass die Entwickler
sich es anders überlegt haben oder dass sie vielleicht
in ein anderes Projekt reingemerged sind.
Es kann nicht sein, dass auf einmal so ein Ding fertig ist.
Das kann auch sein,
aber es ist unwahrscheinlich.
Wann wird Software je fertig?
Und jede neue Version
von Django bietet natürlich auch
Möglichkeiten, Dinge wieder neu oder anders oder
einfacher zu machen und dann eigentlich
wahrscheinlich nicht immer, aber ab und zu muss man
halt doch mal was anfassen und
wenn man nichts mehr anfassen muss, dann
muss man halt
ja, eben ist es eher ein Zeichen dafür,
dass es nicht mehr richtig maintained wird.
Und ja, Django Packages
wird übrigens von einem der beiden
Autoren
in Diskurs auf Django
betrieben,
dem, der auch
Crispy Forms geschrieben hat,
was erklärt, warum es die Präferenz ist.
Ja, also die
machen da ganz viel und
ja, Django Packages
ist tatsächlich eine große Hilfe, aber
ja, so oft ist es auch schwer zu erkennen,
also ich finde das oft nicht so
einfach, wenn man jetzt irgendwie ein Problem hat,
das man gelöst haben möchte
und man jetzt hat, hat man da so eine Auswahl
von zehn unterschiedlichen Paketen,
ist es wirklich nicht einfach zu sagen,
ja, welches davon
man nehmen sollte.
Ja, ohne jetzt alle zu kennen schon.
Genau, das kann man ja auch gar nicht, man kann die gar nicht alle kennen
und selbst wenn man dann mal zwei, drei
reingeguckt hat, dann
ist das nicht so einfach zu sagen.
Ja, manchmal muss man halt dann Glück haben oder
irgendwie sich später nochmal umentscheiden,
aber das ist
tatsächlich ein großes Problem, also
wie wählt man
die Software aus, von der man
abhängig sein möchte, das ist
Ja, und jeder
baut so mit der Zeit seine eigenen
Vorlieben und seine eigenen Präferenzen auf
und die sind schwer
austauschbar. Es ist super interessant,
sich darüber zu unterhalten, aber
sie sind sehr schwer austauschbar.
Ja.
Gibt es was wie gute und schlechte
Module oder ist das eher nur eine
Präferenzenfrage?
Es gibt sicherlich gute
und schlechte Module, aber
nicht auf so einer absoluten
Ebene. Also ich könnte jetzt nicht auf irgendeinem Modul
zeigen und sagen, das ist schlecht. Wenn du das benutzt,
dann bist du ein schlechter Mensch.
Es ist eher...
Das Cookie-Law-Modul
vielleicht.
Wenn man keine Cookies eigentlich einsetzen müsste.
Wenn man keine Cookies hat.
Aber es gibt ganz viele Leute, die sowas anschalten
und gar keine Cookies haben oder so.
Ja, aber das ist ja in Django immer so. In Django hast du immer den Session-Cookie.
Session-Cookie. Also müsstest du eigentlich immer...
Musst du immer, ja.
Auch wenn du Session-Scar nicht benutzt hast, hast du immer einen Session-Cookie.
Also müsstest du eigentlich immer
das Modul direkt einschalten.
Muss man die Cookie-Warnung tatsächlich auch bei Session...
Ich dachte nur, wenn man tatsächlich ein persistentes Cookie
setzt im Browser...
Soweit ich weiß,
immer wenn du
Informationen über den Benutzer
speicherst, dann das tust du ja in dem Moment.
Okay, dann muss man es immer.
Okay, das klingt super.
Also nach...
den Themen, die wir schon immer machen wollten.
Ich glaube, Artikel 6
oder sowas ist da spannend. Da kann man einfach sagen,
hey, das muss ich machen, deswegen darf ich das auch.
Und da müsst ihr einfach mit zufrieden sein.
Ich muss euch da gar nicht Bescheid geben und gut ist.
Ja, klar. Es gibt ja auch
verschiedene Arten, wie man damit umgehen kann.
Ich habe neulich eine Cookie-Warnung gesehen.
Da stand einfach nur drin, wir müssen sie informieren,
dass wir Cookies setzen. Das haben wir hier mitgetan.
Ja.
Da kann man sich ja vor Gericht streiten, ob das ausreichend war.
Ja, aber...
Ja.
Mir fällt das schwer,
das zu verstehen manchmal, was da
bestimmte Regulierungen irgendwie eigentlich nutzen sollen.
Und Leuten, die da noch weniger
an zum Beispiel EU-Verordnungen dransitzen
in den USA, denen fällt das möglicherweise noch schwerer.
Und dann kriegt man teilweise so
fast schon passiv-aggressiv
anmutende so Geschichten so.
Willst du die Seite wirklich weiter benutzen?
Dann drück jetzt hier.
Vermeldung.
Ja. Naja, gut.
Wahrscheinlich muss man einfach damit leben, dass es halt manchmal ein bisschen nervig ist,
wenn man regelgeregelt...
Und dann haben die Leute, die das nicht verstehen,
irgendwann ausgedient. Und dann kommen Leute, die es ein bisschen besser verstehen,
die sagen dann, mach den Schrott weg.
Oder so. Hoffentlich.
Dann weiß ich es nicht. Kann natürlich immer alles schlimmer werden.
Aber ich glaube mir mal an das gute Menschen.
Ja.
Das ist ja immer Politik. Zwei Schritte vor, drei zurück.
Nein, warte mal. Drei vor, zwei zurück.
Hoffentlich.
Oder im Kreis.
Ja, ja.
Ja.
Was habt ihr denn an Neuigkeiten für Dango?
Ist euch da was eingefallen, was in letzter Zeit
da zukam, wo ihr sagtet, ey, wow,
guckt euch das unbedingt nochmal an?
Es gibt da eigentlich immer neue Sachen
zu sehen.
Dango hat vor kurzem seinen...
Ja, vor kurzem. Vor langer Zeit.
Er hat schon seit langer Zeit einen sehr schnellen
Release-Zyklus.
Entschuldigung, was heißt schnell?
Schnell heißt, dass die
sagen, alle neun Monate
kommt eine neue Version von Dango raus.
Immer ein nächstes Baby.
Genau.
Und jede dritte Version
von Dango ist eine sogenannte LTS-Version.
Eine Long-Time-Support.
Oder Long-Term-Support.
Das heißt, dass die mindestens für, Jochen,
korrigiere ich mich, drei Jahre
Sicherheits-Updates gibt.
Und das heißt, dass es
ab jetzt regelmäßig neue Major-Versionen
gibt, weil die eben dieses
Namensschema umgestellt haben. Wir sind jetzt
gerade bei Dango 2.1.
Die nächste Version, 2.2, wird
eben so eine LTS-Version sein,
die dann für längere Zeit
gültig ist.
Oder unterstützt wird, muss man so zu sagen.
Und die Version danach ist Dango 3.0.
Und üblicherweise
erwartet man ja bei
Versionssprüngen immer viele
Neuigkeiten. Und ich glaube, dass das auch hier so sein wird.
Also der Sprung von
1.11, was die letzte, was die
gerade aktive LTS-Version ist, auf 2.0,
da waren schon einige Sachen
drin, die sich deutlich geändert haben.
Was sicherlich, oder
was für mich am offensichtlichsten war, ist
der Sprung von URL zu Path,
wo sich die
Definition der verfügbaren
URLs in Django verändert hat.
Früher
in dem alten URL-Schema hat man einfach
reguläre Ausdrücke angegeben.
Und regulärer Ausdruck ist so eine Beschreibung
für einen Text, für ein Textmuster.
Und wenn dieses Textmuster gepasst hat,
dann ist eben diese passende Funktion dazu
aufgerufen worden. Man musste sich dann aber
immer noch selbst darum kümmern, dass, wenn da
jetzt zum Beispiel eine Jahreszahl drin war,
dass die zu einer Zahl wurde, weil die
natürlich aus diesem Text
erstmal nur als Text rausgekommen ist.
Und dieses Problem haben sie in
2.0 geändert. Das heißt jetzt nicht mehr
URL, sondern Path. Und man gibt eben
nicht mehr so ein Textmuster an, sondern man gibt so
ein Parametermuster an. Und sagt, okay,
an dieser Stelle soll jetzt
ein Integer stehen und den möchte ich gerne
als Parameter Ja gegeben
bekommen. Und dann wird diese URL auch
tatsächlich nur aufgerufen, wenn da eine
Ganzzahl drinsteht, die als Zahl
interpretiert werden kann.
Und das nimmt einem viel
Arbeit weg, weil
man eben nicht mehr dafür sorgen muss, dass die Parameter...
...unterpassen. Ist aber auch
erstmal ein Umdenken.
Wenn man so lange mit den
regulären Ausdrücken gearbeitet hat,
dass man sich daran gewöhnt
hat, dann verliert man oft den Blick
dafür, was überhaupt möglich ist und ob das überhaupt gut ist.
Ja, wobei ich finde,
also reguläre Ausdrücke sind natürlich toll
und man kann sie für ganz viele Sachen verwenden.
Und wenn man sich da mal so
zwei Stunden oder einen halben Tag reingefuchst hat,
dann sieht das für einen auch alles ganz natürlich
aus. Aber
wenn man das halt...
Django entwickelt, dann hat man mit diesen
URL-Patterns eigentlich immer
nur so ab und zu mal zu tun, wenn man halt
irgendwie ein neues Modul reintut oder neue
Views definiert. Und das ist eigentlich gar nicht
so super häufig. Also das kommt schon vor, aber
bei mir ist es jedenfalls so,
dass ich eigentlich fast immer, wenn ich
sowas dann, wenn ich das URL-Pattern
geändert habe, dass ich dann irgendwie in alte
Projekte geguckt habe oder nochmal Doku lesen musste.
Wie macht man das denn jetzt eigentlich nochmal?
Wie geht das mit der Gruppe?
Und dann wird das zu einem Variablen-Namen. Wo schreibt man
den nochmal hin? Kommt das P jetzt davor?
Dahinter? Oder muss ich jetzt da ein Fragezeichen...
Also das
war immer... Ich musste
es immer nachgucken. Und dann... Das ist natürlich irgendwie so ein bisschen
ein schlechtes Zeichen, weil das ist dann
irgendwie nicht intuitiv. Und das ist jetzt mit diesen
Pass-Geschichten tatsächlich deutlich
besser. Also da steht dann immer nur so
Doppelpunkt, also Int
oder String. Ich weiß nicht genau. Es gibt auch gar nicht
so viele. Es gibt noch Slug und
Pass oder so. Man kann sich selber welche
schreiben. Man kann sich selber welche schreiben? Oh, das ist
ja super. Das wusste ich jetzt zum Beispiel auch nicht.
Ist ja voll gut. Ja, man kann
sich selber welche schreiben. Es gibt verschiedene
Möglichkeiten. Du kannst entweder direkt reguläre
Ausdrücke machen. Also wenn du halt
irgendwas ganz Bestimmtes merken musst.
Oder du kannst welche, die es gibt, zusammentun.
Also wenn du zum Beispiel möchtest, dass da
ein Datum steht, kannst du eben drei so
Integer-Dinger hintereinander mit
Bindestrichen getrennt und kannst
das als Date
deklarieren. Und kriegst dann auch automatisch ein Date.
Also musst du halt das entsprechend konvertieren, aber
kriegst dann automatisch immer ein Date zurück.
Und kannst es dann von da an überall verwenden.
Oh, das ist ja großartig. Das finde ich
mal angucken, wie das geht.
Ja. Ja, siehst du, und das ist
so ein bisschen das Schöne. Das ist so ein bisschen das, was
immer passiert, wenn Django
Experten zusammensitzen.
Dann sagt einer irgendwas und der andere sagt, oh, das ist ja cool.
Das wusste ich noch gar nicht. Das muss ich unbedingt mal
anschauen. Ja.
Und das geht mir da eigentlich regelmäßig so.
Ja.
Ja, ich weiß nicht genau, ob
für 3.0 jetzt schon so ein Thema...
Ich habe irgendwie so
am Rande mitbekommen, dass
auch für 2.0 im Grunde schon angedacht
war, ob man jetzt nicht doch
irgendwie so ein bisschen
mehr
ja, wie
Kommunikation
mit dem Client mit in Django reinnehmen kann.
Aber das geht jetzt auch schon seit einiger Zeit
irgendwie
in den neueren HTTP-Versionen, dass man quasi auch
über Websockets wieder mit dem Client
vom Server aus zurücksprechen kann.
Und es gibt diverse
Fälle, wo das ja auch total sinnvoll ist, dass man das
tut. Aber
das passt halt nicht so richtig auf dieses
ja, auf diese
Schnittstelle zwischen
Web-Server und Applikationen.
WSGI, WSGI-Schnittstelle
gibt das halt eigentlich nicht her.
Und da muss halt noch eine ganze Menge
Infrastruktur geändert werden.
Und es gab da dieses Django-Channels-Projekt.
Das gibt's ja immer noch.
Das gibt's immer noch, ja.
Und da war ja irgendwie schon
mal irgendwie quasi
sozusagen angedacht, dass in 2.0, Django 2
mit reinzunehmen. Aber das ist dann halt irgendwie nicht
passiert. Wahrscheinlich, weil zu viel angepasst werden musste.
Und vielleicht kommt das ja dann in 3.0.
Ich hab keine Ahnung.
Das ist eine ganz spannende Sache.
Das muss man sich auch mal genauer angucken.
Weil da viele Dinge möglich werden, die vorher nicht möglich waren.
Ist aber eben
technisch ganz anders. Weil wir ja nicht mehr in
dieses klassische Web-Schema reinfallen, wo
der Benutzer eben eine Webseite aufruft
und dann kriegt er die zurück. Sondern
weil es jetzt eben auf einmal eine Verbindung gibt.
Wo der Server potenziell
selbst sagen kann, hier ist was passiert, mach mal was.
Und das ist eine ganz spannende Sache.
Ja, auch technisch super interessant.
Da haben sie sich einen neuen Standard
mehr oder weniger ausgedacht. ASGI.
Was dann halt
auch neue Server-Backends erfordert.
Daphne heißt der Server. Genau, genau.
Man kann nicht einfach irgendwie Junicorn nehmen oder
den normalen Entwicklungs-Server von Django, sondern
ja. Und da ändert sich dann einiges.
Man kann schon den normalen Entwicklungs-Server nehmen, weil
der das direkt mit integriert hat.
Also wenn du Channels installierst,
dann kriegst du eine andere Variante
von Run-Server und der das automatisch
der automatische Websockets bringt.
Damit du eben in der Entwicklung den
Unterschied nicht merkst.
Aber das
Arbeiten damit ist deutlich anders, weil du eben
diese Kanäle hast und nicht mehr so dieses
Request-Response.
Schema.
Das muss man jetzt mal kurz erklären. Also ich habe jetzt
ganz kurz fast nur Warenverstand.
Request-Response-Schema, ja.
Kanäle, hä?
Was ist das?
Die
früher, als das
Web noch jung war,
war die Idee,
dass eine Webseite eigentlich nie
einen Zustand haben sollte.
Das heißt, du fragst eine URL an
und kriegst das Ergebnis, oder kriegst das,
was da auf dieser URL steht, zurück.
Und mit Error 402
Payment Required, ja. Genau.
Das hat sich dann schnell gezeigt, dass dem nicht
so ist und dass man irgendwie einen Zustand braucht.
Und man hat dann eben die Lösung gefunden, dass man Cookies
setzt. Cookies sind im Wesentlichen
der Zustand, den du mitlieferst, wenn
du eine Webseite anguckst.
Wenn du dich irgendwo einloggst,
dann wird eben der Login auf dem
Server mit dem Cookie, den du
hast, verbunden. Und jedes
Mal, wenn du diese Seite aufrufst,
guckt eben der Server, ist das ein Benutzer,
der eingeloggt ist oder einer, der nicht eingeloggt ist.
Und zeigt dann entsprechend die richtige Variante an.
Ist sehr schön,
weil man da die Seiten eben
so dynamisch generieren kann, dass sie für den
Benutzer zugeschnitten sind, der jetzt gerade
da ist. Weil wir ja wissen, wer sich
eingeloggt hat. Oder weil wir vielleicht wissen, was der
gestern gekauft hat. Oder weil wir vielleicht wissen,
keine Ahnung, was der für
einen Computer hat oder irgendwie sowas.
Ist aber immer noch,
das Schema ist immer noch Request Response.
Der Browser sagt,
ich möchte jetzt diese Seite ansehen, bitte
gib mir diese Seite. Dann macht der Server irgendwas
und gibt ihm diese Seite zurück. Und damit
ist die Arbeit des Servers schon beendet.
Und der Server hat auch keine
Gelegenheit hinterher noch zu sagen, oh halt,
ist doch was anders. Oder
vielleicht hat sich da
in der Zwischenzeit was getan oder vielleicht
passiert irgendwas. Und er wartet immer, bis der Browser
wieder fragt. Genau, die Verbindung ist dann
erstmal weg und der Browser muss dann fragen.
Jetzt haben Browser
in der Zwischenzeit JavaScript bekommen
und haben eben die Möglichkeit erhalten,
zu fragen.
Regelmäßig zu fragen.
Das ist zum Beispiel das, was Twitter macht oder das,
was Facebook macht.
Wenn da ein Newsfeed
sich aktualisiert, dann fragen die halt
alle 30 Sekunden, gibt es was Neues für mich?
Und dann sagt der Server in den allermeisten
Fällen nein. Und wenn es doch was Neues gibt,
dann gibt er eben diese Schnipsel zurück, die neu
sind oder gibt die Informationen zurück, die neu sind
und der Browser baut die dann für sich zusammen.
Jetzt wäre
es doch eigentlich von der Denkweise
her viel besser, dass der Browser nicht
alle 30 Sekunden fragen muss, gibt es was Neues?
Und ganz oft die Antwort bekommen
wird, nein, es gibt nichts Neues.
Sondern es wäre doch eigentlich besser, wenn der Server sagen
könnte, wenn es was Neues gibt,
hier, bitte nimm. Genau.
Wenn es was Neues gibt, sage ich dir Bescheid.
Und das
ist eben genau diese
Veränderung. Auf einmal hast du nicht mehr
einen Server, der nur noch Fragen beantworten
kann, der Anfragen
umsetzt und
dann die komplette Seite zurückschicken kann oder eben
auch Teile von der Seite, sondern du hast
jetzt in dem Schema die Möglichkeit,
zu sagen, es ist
ein Ereignis passiert auf dem Server
und der Server gibt
automatisch dem Client Bescheid.
Dafür brauchst du aber eine Verbindung zwischen dem Server
und dem Client, die die ganze Zeit da sein muss.
Ist das nicht dann das Netz
viel mehr ausgelastet?
Nee, es ist eigentlich weniger ausgelastet.
Weil du eben nicht die
ganze Zeit leere Anfragen schicken musst.
Gibt es was Neues? Gibt es was Neues? Gibt es was Neues?
Gibt es was Neues? Sondern du hast nur diese eine
Verbindung und die, klar, die wird offen gehalten.
Also insofern hast du eine Ressource,
belegt. Aber dieses
Verbindung offen halten ist sowieso was, was
TCP kann und das wird eben über so
Keep-Alive-Mechanismen, die sich dann
anpassen, die möglichst wenig Bandbreite
verwenden, abgedeckt.
Und du hast wirklich nur Kommunikation,
wenn auch tatsächlich was passiert.
Und das
gibt dir eigentlich zwei Vorteile. Zum einen
sparst du dir die Bandbreite, dass du die ganze Zeit
fragen musst, auch wenn nichts passiert ist.
Du weißt ja gar nicht, was passiert ist. Und zum anderen
hast du natürlich eine viel schnellere Antwortzeit.
Weil es nicht
mehr davon abhängt, wie oft der Client
fragt, dass er Updates bekommt,
sondern wenn ein Update passiert,
kann der Server sofort sagen, jetzt ist was passiert.
Das heißt, wenn ich
mir meine Chat-Anwendung schreibe
und die, das ist so das klassische
Beispiel, und der
Client fragt halt nur alle 30 Sekunden, gibt es was
Neues? Dann sehe ich auch nur alle
30 Sekunden, ob jemand was geschrieben hat.
Wenn der Server sagen kann, hier ist was Neues,
dann kann ich das sofort ausliefern. Das heißt, es wird
sehr viel
responsiver, sehr viel
schneller in der
Verarbeitung. Und Latenz
direkt verfügbar. Genau, es wird direkt
weitergeleitet und direkt verfügbar gemacht.
Und das ist natürlich was, was man heutzutage haben
möchte, diese Geschwindigkeit
in den Antworten.
Auch in ganz mondänen
Anwendungen,
immer dann, wenn ich irgendwas anzeigen möchte,
was auf dem Server passiert,
brauche ich diesen
Update-Mechanismus oder kann ich diesen Update-
Mechanismus. Also immer ein Request und das
ist halt jetzt ein Riesenvorteil.
Genau.
Ja, und ich glaube,
es gab da auch
noch Dinge, bevor man das
mit JavaScript gemacht hat,
solche furchtbaren Dinge wie Long-Polling,
wo dann der Server immer gesagt hat,
ja, nee, Moment, warte mal, ist noch nicht
ganz fertig, warte mal,
Moment.
Und dann ab und zu mal doch wieder so ein
Content-Bröckchen an den Client weitergeschickt hat.
Und es gab da
diverse furchtbare Geschichten, die gemacht wurden.
Und im Grunde jetzt
WebSockets und eine
stehende Verbindung löst all das eigentlich
relativ sauber und
ja, damit kann man wirklich tolle Sachen
machen.
Und es gab ja auch,
es gibt auch schon komplette
Frameworks und komplette
Technologie-Stacks,
die halt darauf basieren, dass man
sowas machen kann. Also wenn man zum Beispiel in die JavaScript-Welt
guckt, da Meteor oder so, die sind halt,
das ist halt vom Backend
bis zum Frontend darauf ausgerichtet, dass
man dem Client
irgendwie Dinge schicken kann.
Und damit kann man halt Sachen bauen, die
ja,
wenn man sowas zum ersten Mal sieht, relativ verblüffend
aussehen, weil sie anders
sind als das, was man so von Web-Anwendungen
gewohnt ist.
Jetzt hast du gerade wieder einen Begriff gesagt, ein Meteor.
Ja, das ist halt dieser Stack, das ist heute auch
nicht mehr so relevant, das ist immer eine Zeit lang irgendwie
halbwegs hip.
Und das ist halt irgendwie, als
Datenbank verwendet das halt irgendwie
dieses da, Dings da,
MongoDB.
Das kann halt quasi
diese Verbindungen
auch, oder wenn was irgendwie passiert,
direkt wieder an
den Server, dass dann
irgendwie ein eigenes Node.js-Basics
Dings irgendwie weiterreichen. Und deswegen
reicht es halt komplett durch an den Client.
Und du hast halt sozusagen Model-View-Kontrolle
aber mit
dem Client direkt drin. Und auf dem Client
oder auf dem Server kann der gleiche Code laufen und so.
Und das ist alles sehr schick.
Damit sieht dann halt so eine Anwendung quasi genauso aus wie
eine
ähm
ja, wie so eine Desktop-Applikation
im Grunde, was die
Reaktivität angeht. Man drückt irgendeinen Knopf
und sofort bei jemand anders in einem
anderen Browser irgendwie
sieht man, dass dieser Knopf gedrückt wurde.
Und ähm, das ist fast
ja, also
Statusänderungen sind halt sozusagen
instantan für alle, die es betrifft,
sichtbar. Und das ist halt etwas, was man normalerweise
jetzt so nicht hat. Das hat man auch bei Django nicht.
Das kann man dann schon machen, aber das ist dann halt
immer irgendwie so eine Sonder-Locker und das ist halt nicht
irgendwie in dem Framework mit,
integriert, sondern, ähm, ja,
halt immer so ein bisschen, äh, dran
vorbei.
Ähm, aber das wäre natürlich schön, wenn man das halt
direkt mit drin hätte. Und das kann natürlich gut sein,
dass das jetzt demnächst dann in einer größeren, äh,
Major-Version kommt.
Ja, ansonsten kann man sich Channels ja auch so
reinholen. Ja, kann man auch.
Also, implementiert Django dann
Module, die es vorher schon gab, oder bleibt es komplett
eigene Dinge selber? Sind da
vorher so Requests für vorhanden,
dass tatsächlich die Entwickler gucken, hey, was ist
denn so an Bedarf da, oder kommen die mit eigenen
kreativen Ideen, oder?
Ja, es, äh, es gibt, äh,
Django ist, ähm,
ein sehr großes Open-Source-Projekt.
Und, ähm... Wie viele Entwickler
gibt es da ungefähr in diesem...
Es ist schwer zu sagen, aber es gibt eine Stiftung.
Es gibt die Django Software Foundation. Also, sie sind
irgendwann so groß geworden, dass sie eine Stiftung gegründet
haben. Also Leute, die
Vollzeit auch ein bisschen dafür bezahlt werden, dass sie wie Moodle weiterentwickeln.
Genau, da gibt es so ein paar Programme,
wie das, äh, wie das, wie das möglich
ist, und die haben auf jeden Fall genügend,
äh, finanzielle Ressourcen,
um sich am Leben zu halten, und um eben dieses
Projekt, äh, am Leben zu halten.
Heißt eben aber auch, dass, äh, dass da
inzwischen relativ viel Community-Management
drin ist, weil eben die Community
so groß ist, weil es so viele Leute gibt,
die Django einsetzen,
dass es notwendig
wird, da Prozesse zu haben.
Die, der, die meiste
Weiterentwicklung kommt, glaube ich, tatsächlich aus der
Entwickler-Community, wo einer,
der es haben möchte, einfach sagt, ich mach das
jetzt mal, und dann zeige ich es allen Leuten,
und wir schauen, ob das funktioniert
oder nicht. Also es ist sehr viel da,
es ist nicht so zentralisiert,
wie man das in, in anderen Projekten vielleicht
kennt, sondern es passiert sehr viel einfach
aus der Community heraus.
Es gibt auch, äh, jedes Jahr Konferenzen
zu dem Thema, es gibt die DjangoCon,
die jedes Jahr in den USA stattfinden,
es gibt die DjangoCon Europe,
die jedes Jahr in einer Stadt
Europas, äh,
Wo ist sie nächstes Jahr, und wo war sie dieses Jahr?
Dieses Jahr war sie in Heidelberg,
im Mai. Ja?
Ach, in die Ecke.
Ja, es ist in Kopenhagen, wenn ich das richtig
weiß. Und das wird auch
immer von, äh, von der Community
organisiert, also die Software, die DSF,
die Django Software Foundation sagt, ganz
spezifisch, wir wollen, dass das Amateure
machen, weil wir eben
die, die
Community, die Benutzer mit einbeziehen
wollen in den Prozess
der Weiterentwicklung.
Und, äh, die DjangoCon Europe
ist, vor ein paar Jahren war die in Südfrankreich,
und da hatten sie so eine Insel, die hatten
einfach eine komplette Insel gemietet.
Ja. Hübsch. Das ist jedes Mal
anders, und das ist auch so ein bisschen der Reiz da dran.
Warst du da? Ich war letztens, in Heidelberg
war ich da zum ersten Mal. Ja? War,
war sehr angenehm, war eben
hinter dem, vor dem studentischen Hintergrund
Heidelbergs, äh, auch ganz nett.
Nächstes Jahr in Kopenhagen werde ich
wohl nicht dazu kommen können, aber
ich war schon mal in Kopenhagen, das ist auch sehr schön.
Und ich
kann es eigentlich jedem nur empfehlen, und jede DjangoCon Europe
ist so ein bisschen anders, weil die eben
von Leuten
aus dieser Gegend, ähm,
organisiert wird, die vorher vielleicht noch nie
so eine Konferenz organisiert haben. Also auf der nächsten Insel
schaue ich wahrscheinlich auch mal vorbei, oder? Ja.
Es lohnt sich auf jeden Fall.
Ja. Es ist super, da die Leute
kennenzulernen, und man hat auch
Kontakt da mit den, mit den
Core-Entwicklern, also mit den Leuten, die sich
tagtäglich damit beschäftigen, und das ist natürlich super.
Und gerade jetzt bei
dem Janos-Projekt, ähm, ich hab da
auch ein paar Leute kennengelernt, und hab dann auch
direkt was mit denen zusammen
angefangen zu bearbeiten.
Oh, ja, das gibt ja auf jeden Fall schon was.
Nicht gut. Ja.
Ja, ansonsten,
ich weiß gar nicht, äh,
inwiefern
das da mit reingreift,
äh, was halt auch interessant wäre,
äh, es gibt ja in Python jetzt so eine,
ähm,
äh, ziemlich schicke Syntax für
AsyncIO, und, ähm,
was eigentlich ja schon immer toll
gewesen wäre, aber nie so richtig geklappt hat, war,
äh, dass man diese Asynchronizität,
die man nach draußen hat, mit den
Requests, der Prequests,
die halt reinkommen, dass man die halt weiterreicht,
sondern, äh,
zum Beispiel an, an, an Datenbanken
oder irgendwelche APIs, die man fragt, ähm,
so momentan ist es halt so, wenn man jetzt,
weiß ich nicht, äh, um eine Seite zu bauen, zehn,
zehn Statements irgendwie an die Datenbank schicken
muss, dann werden die halt da, äh,
seriell hingeschickt und, äh, abgearbeitet
und dann, wenn die fertig sind, dann zeigt man
die Seite an, was ein bisschen doof ist,
weil das halt jedes Mal die Latenz,
also die halt durchaus ein paar, oder auch
vielleicht mal ein paar zehn Millisekunden sein kann pro
Statement, das addiert sich halt alles auf,
und dann am Schluss, äh, äh, quasi
äh, hat man halt, äh,
ist, ist die Zeit, die man
braucht, um halt quasi Content auszuliefern,
das ist ja eine wichtige Zeit, weil erst
ab da ja alles losgeht, auch wenn man hinterher,
äh, äh, Bilder parallel holen kann
oder so, äh, das geht aber nur,
wenn man weiß, wie die Build-URLs sind, das heißt,
solange nicht irgendwie ein, irgendwie Content
vom, vom, vom Applikations-Server gekommen ist,
kann gar, passiert nichts weiter.
Holst du noch mal einen Kaffee?
Genau, und, äh,
dummerweise sind halt in diesem, diese
kritischen Zeitbereich halt, äh,
äh, solche Dinge wie halt, dass
alle, äh, SQL-Statements
und Seriele geholt werden müssen, und das ist natürlich eigentlich
ziemlich blöd, und schöner wär's ja, wenn man irgendwie
alle gleichzeitig abfeuern würde, und dann
würde man dann die Halter irgendwie so einsammeln,
und dann wäre, äh, sozusagen das,
ja, längste Statement, äh, irgendwie
vielleicht das, was darüber entscheidet, wie lange es dauert,
aber, äh, man müsste nicht, äh,
irgendwie, äh, äh,
äh, quasi auf jedes Einzelne warten,
das könnte die Zeit deutlich verringern,
und, ähm,
ja, ähm, im Grunde könnte man da auch
eine ähnliche Schnittstelle verwenden wie für, für,
für, äh, äh,
für Asynchro-Initial, äh, äh, für,
für Asynchro-Geschichten nach vorne raus,
und, ähm,
da weiß ich gar nicht, ob's, äh, und bisher war das
halt immer problematisch, weil man kann's halt irgendwie mit
den vielen unterschiedlichen Geschichten, die es in Python
da gibt, machen, man kann Threads nehmen, man kann halt
irgendwie Twisted nehmen
oder so, aber...
Frido hab ich letztens kennengelernt.
Ja, das ist auch, das ist voll super, aber, ähm,
äh, ja, äh,
äh, im Grunde, jetzt hätte man halt die Möglichkeit zu sagen,
okay, da wir jetzt dann eine Syntax für haben,
dann machen wir das einfach so, und das wäre
natürlich auch eine interessante Geschichte, ich weiß auch, dass Flask,
äh, irgendwie, dass da zumindest
ein Projekt gibt, das versucht, Flask dahin umzubauen,
dass das halt alles, also,
IO-kompatibel sozusagen ist,
und, äh, bei Django weiß ich jetzt gar nicht
wieder, wie weit das ist, oder ob's da überhaupt Bestrebungen gibt,
ähm, aber sowas wäre natürlich
auch sehr nett, keine Ahnung, ja.
Ja, wüsste ich jetzt auch nicht,
aber es hört sich so an, als ob du mal ein, äh,
Enhancement-Proposal einlassen solltest.
Haha, und vielleicht
ein Fellowship beantragen, das wäre auch was.
Ja.
Tja, tja, tja, ist wahrscheinlich auch
nicht so einfach, muss man sagen.
Ja gut, aber wenn's einfach wäre,
dann wäre es auch langweilig.
Das hätte auch schon wahrscheinlich jemand gemacht, ja.
Ja, ja.
Wir machen das nicht, weil es einfach ist, sondern wir machen das,
weil es schwer ist.
Ja.
Was gibt's noch so an
interessanten Django-Themen?
Ach ja, vielleicht sollte man das auch noch erwähnen.
Genau, ähm,
die Art, wie dieser Podcast
publiziert wird, also, genau,
natürlich auch gedacht, so, okay,
äh, wenn ich, wenn ich da jetzt schon
irgendwie Django, äh,
entwickle, dann ist es ja eigentlich, wäre das ja
jetzt eigentlich schon ziemlich beschämend,
irgendwie WordPress zu nehmen, um
Podcasts zu veröffentlichen.
Und, äh, dann hab ich halt meinen, meinen,
äh, mein kleines Blog-Modul genommen, das, äh,
das ich mal irgendwann geschrieben hab und, äh,
da jetzt auch so Podcast-Funktionalität, äh,
äh, reingedingelt.
Und, ähm,
äh, mal gucken, wie weit das, äh, wie weit das trägt.
Äh, ähm, aber, äh,
das war alles gar nicht so schwierig, ja.
Also, zum Beispiel, wo einem Django da schon
sehr hilft bei, ist, dass, äh,
es gibt so ein, äh, äh,
Feed, ähm,
Syndication-Feed, äh,
App, also Django selbst enthält
einige Apps, unter anderem halt,
äh, Admin oder, oder Contrib,
äh, äh, also Authentication
und so Zeugs. Und halt
auch ein, ein Feed-Syndication-Framework, mit dem man halt
Feeds generieren kann. Und das ist natürlich total hilfreich,
äh, wenn man das halt nicht selber machen muss,
weil das ist irgendwie ziemlich, äh,
ziemlich fies.
Und, ähm, ja, das,
äh, das, das war eigentlich sehr angenehm.
Was natürlich irgendwie, das, was immer noch ein Problem
ist, ist, dass man dann halt irgendwie so
diverse Feinheiten berücksichtigen muss. Man muss halt gucken,
oh, äh, wenn ich jetzt,
äh, das auf dem eigentlich
einzig relevanten, äh,
äh, Katalog,
im einzig relevanten Katalog veröffentlichen will,
das ist halt der iTunes, äh, Podcast,
das iTunes-Podcast-Verzeichnis,
dann gibt es halt noch so ein paar
Spezial-Äh, Attribute, die halt iTunes
haben will, und die müssen halt richtig gesetzt
sein, und das will halt die Bilder in einem bestimmten Format
haben, oder das, das Artwork zu dem Podcast.
Und, ähm,
ja, Kategorien
müssen ein bestimmtes Format haben und so Dinge.
Ähm, da hab ich jetzt nochmal so
ein bisschen knabbern müssen, aber so,
einfach nur, dass man dann, äh, RSS
oder Atom-Feed hat, wo die, wo die
Episoden, äh, quasi,
ähm, drinstehen, das war
relativ einfach, ne, das war auch sowieso bei dem,
bei dem Blog-Teil war das halt
sehr simpel, das waren halt irgendwie, keine Ahnung,
15 Zeilen Code oder so, und dann gab's ein RSS-Feed
zu den, zu den, äh, Blog-Posts.
Das heißt, wenn ihr euren eigenen Podcast
machen könnt, könnt ihr jetzt demnächst, äh, Jochen,
das Modul dafür verwenden. Ja, kann man
tatsächlich, äh, so, sag mal so, das ist halt nicht,
äh, äh, gut dokumentiert und, ähm,
ähm, wahrscheinlich alles,
irgendwie noch ein bisschen experimentell, aber so,
ja, benutzen kann man das
schon, wenn man, äh,
ein bisschen furchtlos ist.
Und, und,
ein Bastler, ein Bastler.
Ja, das ist ein bisschen was für Bastler, muss man schon
sagen, ja.
Ja, genau, und das ist natürlich dann auch
eine gute Gelegenheit, um immer wieder was über, äh,
Django zu erzählen, wenn da, äh, irgendwelche Probleme
aufgetaucht sein sollten oder, äh, irgendwelche schönen
eleganten Lösungen möglich werden.
Ja.
Also ich, äh, ja,
ähm,
ich bin da, ich bin da eigentlich durchaus angetan. Also auch
die, die Erfahrungen irgendwie mit dem, mit dem
Blogschreiben in Django, das war auch eigentlich alles sehr,
sehr nett. Äh,
ähm, ja.
Man kann, man kommt, aber was auch
interessant ist, ist halt, äh,
ist es auf der einen Seite halt sehr, sehr viel
da schon, was man verwenden kann.
Wenn man jetzt aber tiefer bohrt, dann kommt man auch immer
relativ schnell an, an, an
Stellen, wo man sich sagt so, hä,
da gibt's noch nichts, das hat noch nie jemand irgendwie.
Und das ist halt schon so, äh,
äh, also zum Beispiel bei den Bildern
wieder, also, vielleicht gibt's da auch
was, oder ich weiß es, und ich weiß es einfach noch nicht, das kann natürlich auch
sein, aber, ähm,
äh,
dieses Django-Image-Kit löst in gewisser Weise
ein Problem, halt dieses, äh, vorberechnen
der, der, äh, unterschiedlichen Bildgrößen.
Aber wie es das tut, ist halt nicht
so richtig toll. Und da gibt's dann wieder, soweit ich weiß,
nix. Also, äh, es gibt da ja
äh, tolle Möglichkeiten. Es gibt so,
äh, ähm,
LibJPG-Turbo oder, äh,
Mods.jpg, die halt
ungefähr nochmal so mindestens
ein Drittel, äh, die Bilder
kleiner machen bei gleicher Qualität oder auch
dafür sorgen, dass, wenn ein Bild angezeigt wird
und das geladen wird, dann werden halt zuerst grobe
Geschichten angezeigt und dann halt feinere
Sachen, so, äh, das kann man mit
JPEG halt irgendwie machen. Und,
ähm, ja, ähm,
defaultmäßig wird aber Pillow verwendet. Pillow
verwendet irgendwie unten drunter ImageMagic oder so.
Und das ist alles
nicht richtig optimal. Also, da kann man zwar angeben,
wie hoch die Qualität sein soll,
aber, äh, die Bilder sind halt
nicht so klein, wie sie sein könnten, was, äh,
für die meisten Leute vielleicht kein, kein großes Problem
sein wird, aber wenn man jetzt irgendwie ein paar tausend Bilder
hat, dann macht das durchaus was aus.
Oder ich hab mal so ein, ich hab, ich hab auch einen,
einen Block mit relativ vielen Bildern drin
und war dann irgendwie, dachte ich,
dann hörte ich immer so Klagen von Leuten, die sich
das angeguckt haben. Äh, das dauert
immer so lange. Ich hab das gar nicht so gemerkt. Gut,
ich hab hier irgendwie so 100 MBit, was jetzt auch nicht so furchtbar
schnell ist, aber da, da ging das eigentlich ganz flüssig.
Und dann hab ich halt immer so in den,
äh, äh, die LibJPG-Truber
geguckt und so, und gesehen so, oh,
äh, so die ersten fünf Artikel
holen mit vielen Bildern drin, das sind halt so
200 MB. Wenn man sich das auf dem Handy
auf Edge anguckt, dann kann ich mir durchaus vorstellen,
dass das ein bisschen langsam ist.
Ähm,
ja, äh, und
da, da wär's schon schön, wenn man da halt
tatsächlich, äh, quasi default-mäßig
äh, auch irgendwie, äh,
gute Ergebnisse bekommt, aber das ist halt, äh,
irgendwie, äh, momentan jedenfalls
noch nicht so. Und da wär's natürlich auch interessant, wenn da,
äh, also man, man, man,
man stößt relativ schnell auf, auf Ecken, wo man
eigentlich was verbessern könnte, wenn man dann mal Zeit hat.
Und, ähm, ja.
Tja. Johannes, wo ist dein
größter Struggle?
Das, äh,
das, äh, das ist wie beim Johannes, das sind die Details.
Ähm, man
kommt sehr schnell so
zu den 95 Prozent des Projektes,
die eigentlich so smooth
sailing sind, die
man am ersten Tag durchkriegt.
Und an den letzten 5 Prozent arbeiten wir dann
die nächsten zwei Jahre. Also es ist, äh,
äh, es, es
ist schwierig zu sagen, welcher Bereich
am schwierigsten ist, weil es eben oft
an diesen ganz kleinen Details hängen bleibt.
Hast du da was
selber für gebaut, was du irgendwo
mal offengestellt hast?
Es gibt so ein paar Sachen, die ich, äh, die ich mal
gebaut hab und offengestellt hab. Oh, erzähl mal.
Es, äh, die sind alle schon etwas
älter.
Ähm, die meisten Sachen,
die ich in den letzten Jahren gemacht hab, waren eben für
Kunden. Und dann ist es schwierig, äh,
denen zu sagen, hier, ich hab,
äh, so und so viele Stunden dafür abgerechnet,
wie wär's, wenn wir das jetzt der Welt
umsonst geben.
Deshalb sind die meisten Sachen, die ich in den letzten Jahren gemacht hab,
eben hinter, hinter Gittern. Die müssen leider
hinter Gittern bleiben.
Eine Sache, die ich
vor Jahren mal in Python gemacht habe, äh,
ist eine Bibliothek für Kommandozeilen.
Aufrufe. Hat jetzt überhaupt gar nichts mit Django
zu tun. Ähm.
Verlinken wir natürlich auch in den Show noch.
Natürlich. Kommandier heißt die Bibliothek. Beste
Kommandozeilen-Bibliothek, die es gibt.
Ähm.
Weil es einfach ein Problem war, was mich
gestört hat. Ich wollte gerne einfache
Programme mit der Kommandozeile ansprechen.
Oder eine ansprechende Kommandozeile
anbieten können. Und
die Lösungen, die es gab, haben mich alle nicht überzeugt.
Also hab ich meine eigene gemacht.
Das,
das ist so ein bisschen das, was man, was
von einem erwartet wird. Und was man natürlich dann
auch gerne macht. Weil,
weil man ja nicht der Einzige ist, der dieses Problem
hat. Vor Jahren hat
der Python Package Index immer noch
Downloadzahlen angezeigt. Und
die sahen eigentlich schon immer ganz
gut aus für meine kleine Bibliothek.
Inzwischen zeigen sie die nicht mehr an.
Ähm. Ich weiß also nicht, wie viele Leute
das verwenden oder nicht. Ähm.
Aber so ein kleines bisschen Validierung
kriegt man da schon von der Gemeinde
zurück. Okay. Klingt
spannend. Sehr schön nutzlich.
Ja.
Da haben wir doch noch ein bisschen
Streichwerbung gemacht für die Open Source Pakete hier.
Ich bin begeistert.
Ja, für kostenlose Dinge Werbung machen.
Ist, äh, nicht so schlimm.
Durchaus erlaubt.
Äh, genau.
Was fällt euch denn noch zu Django ein? Haben wir noch irgendwas
bei den Themen offen? Was vergessen? Irgendwie was von
Tipps und Tricks, die gerade noch so
unter den Fingern brennen, die ihr gerade noch
mitbekommen habt? Ah, so viele.
Es gibt so viele Sachen. Wir könnten, glaube ich, tagelang
über Django und über
die verschiedenen Bauteile reden. Und
was jetzt, äh, besser ist und
was schlechter ist, dass es mir echt schwerfällt
eine Auswahl zu treffen. Ja, doch.
Vielleicht eine Geschichte, die ich, äh,
im Test sind ja eine relativ wichtige
Geschichte und, ähm,
äh...
Da ist jemand wach geworden. Ah, ja.
Und wütend.
Naja.
Hoffen wir mal, dass ich das recht...
Ja, das ist immer sehr
schmerzhaft. Er kommt tatsächlich direkt
kreishoch.
Ja, genau. Und, äh, da gibt's,
äh, also ich bin da,
ich bin ein Fan von PyTest
eher als von dem eingebauten
Unitest-Framework in Python und, ähm,
äh, da gibt's dann
auch diverse Hilfspakete,
die einem das erleichtern, äh,
irgendwie, äh, zum Beispiel,
ja, PyTest-Django
oder PyTest-Sugar und, äh,
und, und, und diverse
andere. Und, und gibt's noch Dinge, die einem
irgendwie so es erleichtern, ne, so
ein bisschen Fixtures und Daten
zu generieren, so Factory-Boy
und, ähm,
äh, weiß ich gar nicht, was man
da, ob man das wirklich alles empfehlen sollte,
was ich da so verwende.
Ähm,
und, äh, äh, genau, das ist eigentlich
auch sehr, sehr praktisch, ne, also da gibt's halt
dann schon eine existierende Integration, da muss man
sich gar nicht so, äh, ähm,
selbst rumkümmern und, ähm,
das, das
funktioniert eigentlich echt, äh, echt ganz toll.
Also, ähm,
ich weiß nicht, ich glaub, du machst eher Unitest
oder das klassische...
Ja, ich benutze eher die in Django eingebauten,
also die klassischen Unitests. Ich mag PyTest
nicht so gerne.
Aber, aber
da gibt's noch Methodennamen mit
CamelCase viel, viel...
Ja, muss man ja nicht. Muss man nicht?
Nee. Alles, was Test- heißt,
ist ein Test und alles andere ist egal.
Hm.
Nee, das ist, das ist ganz normal.
Dieser, dieser Testrunner ist nicht besonders gut.
Ich benutze immer den Nose-Testrunner, aber das
ist nur eine Kleinigkeit.
Ja, aber, und man muss so Dinge machen wie, man muss
sagen, äh, Assert Equal
und da, da hat man doch auch wieder CamelCase irgendwie
oder Assert... Ja, das stimmt,
diese Assert-Methoden sind so ein bisschen seltsam.
Aber... Ja, gut, ja.
Das, 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 keine, kein grundsätzlichen,
kein grundsätzliches Missverständnis zwischen
uns.
Man sollte testen bleiben.
Natürlich, der Coverage ist
hoch genug.
Und ob die, ob die
Assert-Methode jetzt Assert Equal heißt
oder Assert Equals oder Assert-Equal
oder was weiß ich, wie sie bei,
bei PyTest heißen mag...
Da ist es einfach nur Assert.
Dann sagt man irgendwie, das eine gleiche als das andere oder so.
Ja, das kannst du ja bei einem Unitest
prinzipiell auch machen.
Aber dann kannst du halt nicht unterscheiden zwischen
du wolltest, dass da ein Fehler passiert oder du wolltest
nicht, dass ein Fehler passiert.
Aber das sind auch da wieder nur Detailthemen.
Ob das jetzt so oder so
ausschaut,
ist, glaube ich, gar nicht so wichtig.
Aber wir
kehren wieder zurück zu diesem Thema, was wir
vorhin hatten. Jeder hat so seine
Präferenzen. Und mit der Zeit
findet man halt so die Sachen, die man am liebsten benutzt.
Die ausgelatschten Wege, die dann immer tiefer
werden, weil man immer wieder durchstiefelt.
Und dann kann man nie wieder was Neues anfangen.
Ja.
Ich hoffe, dass wir uns genügend Flexibilität
erhalten haben, um doch immer noch
neue Sachen anfangen zu können.
Immer neu lernen, etwa, heißt ja auch ganz wenig
Wissen und immer wieder von neu anfangen und
ganz, ganz wenig Wissen.
Weiß ich nicht, ob das nur eine Super-Idee ist.
Naja, man muss immer wieder neue Bausteine
suchen und dann... Ach ja, vielen Software,
die man so kennt, fühlt sich schon so an,
als ob die einfach mit ganz
wenig Wissen gestoppt sind.
Ja, das stimmt
natürlich auch. Aber
was man generell sagen kann, ist also
und 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,
da habe ich mich wohl gefühlt, weil das war
etwas, das 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 hinterher
dazukamen oder sich geändert haben, dann
sind immer furchtbare Sachen passiert. Oder nicht immer,
aber häufig genug,
dass es irgendwie
unangenehm war,
schreckliche Dinge passiert.
Die Welt geht unangenehm, ja.
Und seit ich irgendwie
Tests schreibe, ist das eigentlich nicht mehr
so schlimm.
Seitdem geht es los.
Es ist immer noch so.
So ganz lässt sich das nicht verhindern,
aber es ist,
ich fühle mich jetzt wohl
dabei, auch längere Sachen zu schreiben, auch wenn
ich jetzt nicht mehr quasi die Details
anderer
Module oder anderer Apps,
die da auch noch Dinge tun,
wenn ich die nicht mehr so verstehe oder auch
lange nicht mehr daran gearbeitet habe,
dann habe ich jetzt nicht mehr so ein Problem, irgendwas zu ändern,
was die betrifft. Wenn ich hinterher die Tests
durchlaufen lasse und die sehen gut aus,
dann kann ich 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üllt man die Tests aus und dann
schlagen vier Tests Fail und einer davon
schlägt Fail und man denkt sich so, oh Gott, das hätte nie
passieren dürfen.
Dann weiß man,
ja, das wäre jetzt, wenn man keine Tests gehabt hätte,
dann wäre das ein wirklich fieser Wack gewesen
und teilweise sind die halt so, dass man
sich hinterher auch sagt, also da
kommt man nicht drauf, dass das irgendwie die Auswirkungen
hatte, das hätte man jetzt
gar nicht, also durch
lange Meditationen über diese Änderungen hätte man das
nicht wirklich rausbekommen
können. Wäre ihm wahrscheinlich auch gar nicht
aufgefallen und dann irgendwann fliegt es dann
im, ja. Wäre es dem User aufgefallen
oder dann
hätte der sich beschwert, was schon ziemlich schlimm
ist oder noch schlimmer, das wäre irgendwie eine Sicherheitswirkung
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 Tests
benutzen. Verschreibt ihr denn zuerst eure Tests
oder schreibt ihr erst die Code?
Da kann man sich
wenn man die Frage beantwortet, kann man sich nur in den Nesseln
setzen, weil man so viele
Zusendungen kriegt, dass man es anders machen
sollte. Zusendungen habe ich übrigens gerne
an hallo-podcast.de
und jederzeit Fragen, Anmerkungen
stellen. Ich hatte gerade so von das schon
reingepasst, also
keine Aussage von dir, Johannes?
Ich schreibe meinen Code zuerst und schreibe die Tests
hinterher und das schockiert
viele Leute.
Ich mache nicht TDD, ich komme überhaupt gar
nicht klar mit TDD.
TDD ist Test Driven Development. Genau, Test Driven Development
heißt, man schreibt
zuerst Tests und ausschließlich
Tests und dann schreibt man ganz genau
so viel Code, dass diese Tests
erfolgreich werden und nicht mehr.
Die Idee dahinter ist eben,
dass man immer automatisch 100%
Test Coverage hat. Alles, was man an Code
geschrieben hat, ist automatisch getestet.
Weil man den Test vorher geschrieben hat, bevor man
den Code schreibt. Klingt logisch.
Das Problem für mich
ist, dass
Tests sind etwas,
auch wie der Jochen das eben beschrieben hat,
die fixieren die Funktionalität
eines Programms.
Die sorgen dafür, dass ich
weiß, das funktioniert genau auf diese Art
und Weise.
Ich weiß aber oft gar nicht, wie ein Programm
funktionieren soll, wenn ich anfange, das zu schreiben.
Und dann fällt es mir sehr schwer, diesen
Test dafür zu schreiben, wenn ich noch
gar nicht weiß, wie ich es dann tatsächlich machen möchte.
Wie ich denn möchte, dass es am Ende ausschaut.
Und deshalb
fange ich üblicherweise an Code
zu schreiben und dann hat man halt irgendwie so ein paar Sachen
umgesetzt und dann fange ich an die Tests dazu
zu schreiben.
Und dann eben
sozusagen das so weit aufzubohren, dass alles
drin ist, was ich haben möchte und die
Tests. Was ist denn das Gegenargument?
Bist du nicht kreativ genug,
dir vor die Tests auszudenken oder
hinterher wirst du dann zu faul und
die Tests fehlen am Ende?
Ne, ich glaube, es
ist einfach nur ein gewisser Arbeitsmodus,
der
eben zu manchen
Leuten passt und der zu manchen Leuten nicht passt.
Ich bin
immer sehr beeindruckt, wenn Leute
die Idee machen und wenn die das zeigen und ich weiß auch,
dass das super gut funktioniert,
weil die Vorteile eben da sind. Man hat eben immer
Tests geschrieben,
bevor man Code überhaupt schreibt. Also aller Code,
den man schreibt, ist getestet automatisch.
Heißt auch nicht, dass der
100% failsafe ist, aber man kann
auf jeden Fall sicher sein, dass die Dinge, die man in die Tests
geschrieben hat, so funktionieren.
Wie sie funktionieren sollen.
Wie machst du das, Jochen?
Ich muss gestehen, tatsächlich genauso.
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
ein Modul anzuschreiben, wenn
ich irgendwas schreibe. Also quasi
in einer Django-App, so ein
Django-Projekt oder eine Django-Applikation
besteht üblicherweise aus einer Reihe von Django-Apps,
die man halt schreibt. Und dann gibt es halt Third-Party-Apps,
die man sich von irgendwo importiert, wenn man
es installiert hat. Und dann gibt es halt welche, die man selber schreibt.
Also User-Verwaltung ist
üblicherweise ein Teil
und dann kann halt irgendwie, keine Ahnung,
ein bestimmter Teil der Webseite kann halt
irgendwie ein anderer Teil sein oder so.
Und
ja, üblicherweise schreibt man halt
in diesen Apps irgendwas, wenn man
jetzt eine Django-Applikation schreibt.
Aber oft, wenn ich
nicht weiß, wie ich
überhaupt irgendwas machen möchte, dann mache ich
nicht das, sondern ich schreibe Sachen in einem
Notebook.
Das ist
Das ist auch
dein Hintergrund, der da durchkommt.
Ja, ja, natürlich. Also ich mache halt
eher so eigentlich
noch mehr als Django so
Data Science.
Du meinst ein Jupyter-Notebook? Genau, ein Jupyter-Notebook.
Da gibt es auch ein
sehr empfehlenswertes
Paket, nennt sich
Django-Extensions.
Da sind einige schöne Sachen dabei, unter anderem
halt ein Entwicklungsserver, der
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 dann mit Dingen 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.
Jetzt, wenn man...
Wenn man Modelle hat und die Datenbank
ändert sich, dann muss man das halt
irgendwie in der Models-PY machen
und dann muss man halt irgendwie Migrationen ausführen.
Oh, Migration, das ist ja auch so ein Thema.
Aber
wenn es um irgendwie Logik oder so geht,
dass die richtig funktioniert
oder wenn man einfach nur hinkriegen
möchte, dass das jetzt...
Man weiß oft nicht, wie man das elegant
hinschreibt. Und wenn man Sachen
ausprobiert, dafür ist ein Notebook echt total super.
Kann man halt so lange probieren, bis es geht.
Muss nicht dauernd irgendwie
sich darum kümmern, dass man auf der Webseite ist,
irgendwas anklickt oder irgendwie den
Entwicklungs-Server neu startet, weil mit dem Syntax einfach steigt,
der dann aus und dann muss man den wieder 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,
nicht 100% Testabdeckung, sondern
meistens eher so 70 bis 80 oder so.
Weil...
Was auch nicht so schlecht ist,
was halt... Ja, es ist halt irgendwo... Ich weiß nicht
genau, wo der Sweetspot ist. Vielleicht ist er bei noch
ein bisschen mehr, vielleicht ist er bei ein bisschen weniger.
Ich finde,
es ist halt im Grunde
wichtig, dass man so viele Tests hat, dass einem, wenn
was schief geht, das auffällt. Aber
wenn man jetzt so viele Tests hat,
auch wenn man so viel Zeit in den Tests verbringt
hat und halt das Problem, dass man sich dann schon sehr, sehr
festgelegt hat und das hinterher schwer ändern kann,
ähm...
Und die Frage ist, ist es das wert? Ja, wenn das
halt gar nicht mehr so viele Fehler fängt, weil ich
irgendwie anfange... Äh, weiß ich
nicht. Also Dinge, die ich selten teste, sind halt...
Funktioniert das URL-Routing? Ja, 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. Ähm...
Oder das Django-Admin...
Die Geschichten, die teste ich auch eigentlich eher selten.
Also...
Die Logik schon, aber nicht,
ob Admin überhaupt geht. Überhaupt sollte man
nicht unbedingt Sachen testen, die halt schon eigene
Pakete sind, weil die haben schon Tests und so.
Ja, äh, und
ja, für mich ist der, der Sweet Spot
beim Testen eher so bei 70, 80 Prozent
und, äh, äh, ja.
Ein Test, die, die, die,
die man einfach schreiben kann. Das ist ja auch immer so ein Problem,
wenn die Tests zu kompliziert werden.
Also, gut, naja, manchmal schreibe ich das nicht. Manchmal schreibe ich
auch Tests, die komplizierte Dinge tun und dann
hinterher ärgere ich mich immer, wenn ich mir, wenn, wenn die
fehlschlagen und ich dann nicht mehr weiß, was das,
was testet das überhaupt? Warum macht's der Dinge?
Was macht das für komische Sachen?
Du brauchst Tests für deine Tests.
Ja, genau, und das will man natürlich eigentlich
vermeiden, weil dann, äh,
ja, äh, dann wird's schwer.
Wie krieg ich überhaupt so eine Test-Coverage raus?
Also, woher weiß ich denn, wie viel von meiner
Funktion getestet wird? Zähl ich dann einfach
die Funktion, schreibe für jede Funktion eine Test-Funktion
und guck dann und dividiere die dann in Prozenten?
Ja, da gibt's, da gibt's Tools für.
Also, du, äh, da gibt's ein
Tool, das heißt Coverage.
Kreativer Name. Na gut. Und der gibt einem
im Wesentlichen für jede Programmzeile an, würde die
von einem Test berührt oder nicht.
Ja. Und, äh, die Anzahl
der gesamten Zeilen in deinem Programm geteilt durch die
Anzahl der getesteten Zeilen. Okay, also
ganz easy. Ganz easy. Das gibt,
macht einmal eine, eine Ausgabe auf der
Commando-Zeile, aber es macht halt auch, es erzeugt
so irgendwie HTML, äh, und wenn man
das im Browser aufmacht, dann, wenn man
auf die entsprechende Zeile drückt, dann
sieht man halt auch,
meine Ansicht ist kurz und sieht dann halt irgendwie
farblich markiert, welche
Kurzzeilen halt noch nicht getestet sind. Und dann kann man halt relativ schnell
sehen, wenn das halt Zeugs ist, was, wo man
relativ sicher davon ausgehen kann, dass es sowieso
funktionieren wird, wie irgendwie OLCons oder
Die Stereo-Methode. Ja, äh,
dann muss man... Jedes Modell hat eine Stereo-Methode
und das wird nie auf 100%
Coverage, wenn man diese Methode nicht testet.
Aber die ist völlig irrelevant. Ja.
Auf der anderen Seite, wenn man da halt
durchscrollt und sieht dann halt irgendwie ein komplexes
äh, Ding, ein Algorithmus,
der irgendwas macht und der ist gar nicht getestet,
dann sollte man, da sollte man dann vielleicht nochmal
einen Test schreiben, ne? Und so kann man, so
gehe ich jedenfalls vor. Also ich gucke mir halt immer an, was sind die größten Codeteile,
die halt am meisten Funktionalität irgendwie haben.
Wenn die nicht getestet sind, dann fange ich halt da an.
Und, ja.
Es gibt auch ganz viele IDEs,
die das integrieren, wo du quasi diese Ansicht
in der IDE hast, wo du eine Testansicht
haben kannst, wo du eben siehst, welche Zeilen
durchgelaufen sind. Welche IDE nutzt du?
Ich benutze PyCharm.
Ähm, bis vor ein paar
Jahren sind die plötzlich
groß geworden.
Ähm, JetBrains
ist so eine Variante von
einer IDE, die hieß früher
IDE-er.
Die gibt es auch immer noch. Das ist eine Java-IDE.
Ja.
Es ist schwierig, da eine Empfehlung
zu geben, weil auch da die Vorlieben sehr weit...
Dein Polybar hat natürlich auch
Interesse. Genau. Und es ist auch eine
Gewöhnung. Ich weiß auch, dass es nicht die beste
IDE ist und ich weiß auch, dass sie
nicht ungeheuer billig ist.
Aber
ich benutze halt das, was ich gewöhnt bin.
Also Community Edition kann man vergessen, ne?
Die Community Edition kann man nehmen, aber die hat nicht so eine gute Django-Integration.
Gerade was Django angeht,
ist tatsächlich die Professional Edition
deutlich besser, weil die
viele
von den Sachen, die in Django so ein bisschen
implizit sind, trotzdem weiß.
Das ist gerade,
was die Datenbank angeht, ist da sehr viel drin.
Oder Templates auch. Die Template-Syntax
ist in der Community Edition nicht drin.
Ist ein bisschen schade,
aber so ist es
normalerweise.
Ja, Migration
hat es noch angesprochen.
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
App-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.
Man muss dann mal manuell ändern in der Datenbank selber
oder halt einmal komplett resetten.
Ja, genau.
Dann gab es irgendwann
ein
Modul, das nannte sich South.
Das hat dann damit angefangen.
Ich weiß gar nicht, wo die Idee dafür
herkommt.
Für den Namen?
Einmal für den Namen nicht und ich weiß auch gar nicht, wo das...
Das sind, glaube ich, Vogelmigrationen, dass die in den Süden ziehen.
Ach so, Vogelmigrationen.
Ja, schlau.
Ist nur ein bisschen schlecht, wenn man
danach googeln will.
Ja, Django South.
Jedenfalls, diese Bibliothek hat
dieses Problem gelöst, indem 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.
Die hat einfach tatsächlich diese Tabellen, die da drin sind,
verändert.
Wir 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 das ist jetzt
eines der wichtigsten Module in Django.
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. 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ückerranne,
wo wir jetzt gar nicht sowas wie Django verwendet hatten,
zum Beispiel
bei Firmen, bei denen ich gearbeitet habe, sondern
irgendwie selbstgebaute
Webframeworks
oder Dinge, die es schon gab, die
aber sowas alles nicht drin hatten,
da war das immer irgendwie
eine problematische Geschichte.
Da hat man dann halt irgendwie
das getestet, irgendwie
lokal oder auf einem Entwicklungssystem oder
einem Staging-System und hat das dann
funktioniert, dann hat man das Problem, wie synchronisiert man
die unterschiedlichen Schema-Versionen,
was passiert auf dem Produktionssystem,
dann
hat man das irgendwie durchgeführt und dann
ist auf dem Produktionssystem aber was anderes passiert,
als man irgendwie eigentlich erwartet hatte
und dann musste man halt gucken, was ist denn
da jetzt eigentlich passiert und es gab ja 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 sich
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 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,
äh, 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
und 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 äh
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 einem zumindest die Tools an die Hand,
mit denen man das in den Griff bekommen kann,
äh, was halt
äh,
in, wenn man das halt nicht so
macht, sondern von Hand oder selbst
gestrickt halt doch viele
böse Falschtricke für Leute bereithält, äh,
und die dann also relativ unvorbereitet reinlaufen,
ja,
und das ist halt eine Geschichte, die man auf jeden Fall wissen sollte,
dass das gibt, ja.
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
äh, 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 bei der, 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.
Ja.
Aber klar, es ist auch so ein
Fallstrick, äh, 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,
äh,
stolp ich auch regelmäßig noch drüber,
weil ich vergesse meine Datenbank,
die zu migrieren.
Ja.
Dann gibt's keine automatische Erinnerung, also du musst sie dann selber, äh,
Der Operational Error ist die automatische Erinnerung.
Ja, das hört sich auf jeden Fall so an,
sonst könnte man Django 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, äh,
Django-Anwendungen, die man vielleicht so,
ja, die man vielleicht so kennt?
Kennst du denn welche? Ja, ist ja zufällig.
Ja, zufällig.
Ich glaube, einen der größten, äh,
Django, äh,
Implementationen hat
Instagram, oder hat, hat Instagram?
Aber haben sie abgelöst, glaube ich. Haben sie abgelöst?
Oh je, dann war das jetzt kein gutes Beispiel.
Nee, aber sie sind natürlich sehr groß damit gewachsen.
Und, ähm,
das, äh, ist natürlich richtig.
Ansonsten. Was machen die denn jetzt,
weißt du das? Weiß ich nicht genau, nee.
Es ist üblicherweise
so, dass, äh, wenn man solche, äh,
Standardlösungen einsetzt
und dann so groß wird wie Instagram zum Beispiel,
dass man dann auf einmal auf Probleme
trifft, die eben durch Standardlösungen
nicht mehr abgedeckt werden und dass man dann
anfängt, seine eigenen
Dinge zu bauen. Das haben die ganzen
großen Firmen machen das ja, 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
wichtig. Und bei Instagram war es genauso. Die sind
sehr groß geworden mit Django und haben's dann
abgelöst. Soweit ich weiß.
Ja. Fällt dir noch ein anderes
Beispiel ein? Einem von euch?
Es gibt viele kleine
Sachen, die damit
laufen.
Man sieht das von außen natürlich nicht.
Man sieht in der Web-Anwendung nicht an, ob es in Django
geschrieben ist oder nicht.
Ja, ich bin in Django.
Und deshalb muss man so ein bisschen darauf
vertrauen, dass die Entwickler einem das mitteilen.
Es gibt ein System,
das heißt Pre-Tix.
Das ist ein Ticket-Verkaufssystem.
Also wenn man ein Konzert veranstaltet und Tickets verkaufen
möchte, das ist in Django geschrieben.
Die sind auch sehr aktiv
bei den Django-Cons.
Ja.
Also ich weiß das halt auch noch.
Das ist so eine Zeitung in Amerika.
Ja, genau.
Das waren die
ursprünglichen Entwickler
von Django. Also es kommt aus dem
Zeitungsumfeld.
Also auch als Blog-Plattform für
Vertrieb von neuen
News-Artikeln?
Ja, die haben ihre komplette Zeitungs-Webseite
damit organisiert im Wesentlichen.
Also die, ja.
Das ist so die Entstehungsgeschichte.
Das ist aus einer kleinen Stadt in Texas,
Lawrence,
wo eben zwei Entwickler gesagt haben, wir machen
das jetzt einmal richtig, anstatt immer wieder
PHP-Kram zusammenzubasteln.
Haben sie einmal das Problem richtig
gelöst und durften es dann irgendwann
veröffentlichen. Und das System
heißt jetzt Django. Und soweit ich weiß,
wird es da immer noch eingesetzt.
Spannend.
Ja, habt ihr
noch was beizutragen zum Django oder
würdet ihr sagen, wir haben das Thema jetzt so,
soweit, durch?
Es gibt noch
viele Dinge, die man sagen könnte, aber nichts Konkretes.
Wenn wir
irgendein Thema nochmal besprechen sollen, dann sag gerne Bescheid.
Dann machen wir genau da weiter.
Es gibt ja auch diese E-Mail-Adresse,
an die man Fragen schicken kann. Genau.
Hallo at python-podcast.de
Ja.
Ne, mir fällt da jetzt auch
tatsächlich...
Man kann bestimmt auch noch über
diverse
Bereiche in Django,
wie deine eigene Seite machen.
Ja, eigene Episoden.
Episode über den ORM oder Episode über
Template-Sprachen oder so.
Ja, oder auch über ganz einfache Sachen, wie die Formular-Integration.
Oder wie die
Session-Integration.
Ganz einfache Dinge, die man so
für
ganz normal hält.
Für euch ist das ganz normal, easy
und aus dem Ärmel.
Ja, man kriegt das halt automatisch mit.
Wenn man Django einmal startet, dann ist das schon da
und man muss sich nie Gedanken darüber machen.
Es ist super interessant, was damit alles geht
und was vielleicht nicht geht und wie es geht.
Ja.
Und super spannende Sachen.
Was man vielleicht noch erwähnen sollte, also dieser ganze
Web-Stack, also Web ist halt so ein bisschen
was man halt leider auch
immer wieder sieht, dass es nicht so richtig
aus einem Guss, also wenn man sich jetzt
beispielsweise anschaut, wenn man mit Xcode
jetzt iOS-Applikationen
erstellt oder so, dann ist das halt
auch Model-View-Controller, aber es ist halt
eigentlich sehr
schön irgendwie so gebaut,
dass es halt alles von dem
Finger, der irgendwo
draufklickt, bis zu
dem Datenmodell halt alles schön ineinander
greift und funktioniert.
Das ist im Web leider alles nicht so wirklich
und das fällt einem dann halt auch öfter
auf oder auf den Fuß, weil man halt
ganz so viele unterschiedliche
Sprachen
Layer hat, die irgendwie miteinander
interagieren müssen. Jetzt der Django-Teil
ist jetzt nur der
Teil der Web-Applikation, die sich jetzt
auf einem Applikations-Server befindet und
da irgendwie, und der Datenbank-Teil ist halt
auch noch irgendwie mit drin, sozusagen.
Aber, oder es rennt halt auch
HTML nach vorne raus, aber es ist halt auch
das HTML, also die Template selber, ist das jetzt
HTML ein Teil von Django, war ja
eigentlich eher nicht. Das ist
eigentlich nochmal eine etwas andere Welt.
Wie sieht das hinterher aus?
Dazu braucht man dann CSS, das ist zwar auch
irgendwie in Django drin, man kann halt, es gibt da
man kann Sass 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,
überhaupt, wie
SSL, dann die ganzen
Netz, also da ist noch so viel Zeugs mit
dabei, der halt auch eine Rolle spielt,
wenn man jetzt eine Webseite betreibt,
der jetzt nicht unbedingt
Teil von Django ist, da gibt es noch
viel zu tun und das ist natürlich so ein Ding,
also wenn man jetzt einfach nur Django
macht, dann hat man damit die
Komplexität dieses Gesamtdings
irgendwie eine Webseite betreiben
noch nicht komplett abgedeckt.
Also es ist ein ganz guter Teil davon, aber
da gibt es halt...
Das ist auch mal eine Folge, 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,
unter Umständen. Gibt das nicht in Python?
Doch, man kann das auch alles in Python machen, aber ich mach das
auch in Python.
Ne, 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.
Ja, also dann
vielen Dank euch beiden hier, dass ihr so
schön euch unterhalten habt, mir
ein paar Fragen beantwortet habt, die ich so hatte.
Ich glaube, so viel zusammenfassen müssen
wir gar nicht. Wir haben so ein bisschen Dango gemacht heute.
Ja, das war super
und wir haben heute
noch gar nicht über Events gesprochen, aber ich kenne gerade
keine, die jetzt in nächster Zeit sind,
so jetzt am Jahresende.
Ich weiß nicht, ob euch welche einfallen.
12. Dezember ist
Treffen der
Python-User-Group Köln
bei Cologne.
Ja, jede Woche ist halt irgendwie
Python-Fu in Düsseldorf.
Nächstes PyTDF-Treffen ist erst wieder
am 9. Januar, glaube ich. Also
Treffen der Düsseldorfer Python-User-Group.
Falls ihr eure eigene E-Mail-Adresse
anboten wollt, schreibt uns bitte bitte eine E-Mail.
Ja, natürlich. Also ich meine, wir kennen jetzt nur
die Sachen im Rheinland-Düsseldorf-Köln-Umfeld.
Ja.
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.