WEBVTT

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

00:00:05.840 --> 00:00:09.560
Wir haben euch da ein ganz besonderes Thema für euch mitgebracht, und zwar Django.

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

00:00:15.100 --> 00:00:21.500
Wir versuchen auch eine Einführung dazu zu machen, fangen heute ein bisschen an, wieder mit den Basics,

00:00:21.840 --> 00:00:23.600
und dann gehen wir ein bisschen in die Tiefe des Themas.

00:00:24.260 --> 00:00:27.700
Wir sind wieder im wunderschönen Wintergarten hier von Jochen, ich bin der Dominik,

00:00:27.860 --> 00:00:30.460
Und diesmal habe ich nicht nur den Jochen dabei, sondern auch den Johannes.

00:00:31.060 --> 00:00:32.160
Sag doch auch nochmal Hallo, ihr zwei.

00:00:33.140 --> 00:00:36.060
Ja, genau. Hier ist auch Jochen. Hallo von mir.

00:00:37.480 --> 00:00:44.400
Und genau, zum Django-Thema haben wir uns direkt schon mal einen ersten Expertengast eingeladen.

00:00:44.840 --> 00:00:52.340
Und wir hoffen, dass der da irgendwie mehr weiß als wir und uns da viele interessante Geschichten erzählen kann.

00:00:52.440 --> 00:00:55.100
Und das ist Johannes. Und genau, kannst dich ja vielleicht mal vorstellen.

00:00:55.180 --> 00:01:05.340
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.

00:01:07.760 --> 00:01:09.100
Also du arbeitest auch mit Django?

00:01:09.180 --> 00:01:29.240
Ich arbeite auch mit Django, genau. Ich arbeite mit Jochen viel zusammen, der ja auch mit Django sehr viel macht. Und wir haben uns auch darüber kennengelernt im Chaos Computer Club in Düsseldorf in der Python-Ecke. Und haben dann festgestellt, dass wir beide Django machen und arbeiten eigentlich seither zusammen.

00:01:29.240 --> 00:01:30.780
Gut, beim Peißenfudern, donnerstags.

00:01:30.940 --> 00:01:33.080
Genau, jeden Donnerstagabend ab 18 Uhr.

00:01:33.500 --> 00:01:37.540
Ja, die Veranstaltungen kommen erst am Ende, aber wir versuchen das ab und zu nochmal ein bisschen einzustreuen.

00:01:38.240 --> 00:01:42.000
Ja, wir machen heute Dango, deswegen fangen wir vielleicht nochmal ganz am Anfang an.

00:01:42.740 --> 00:01:45.080
Johannes kann, glaube ich, sogar etwas zur Geschichte von Dango erzählen.

00:01:45.140 --> 00:01:46.620
Er ist nämlich genauso ein alter Hase wie der Jochen.

00:01:48.420 --> 00:01:52.320
Wäre doch super, wenn du nochmal kurz erklären könntest, was das ist, wo kommt das denn her?

00:01:53.080 --> 00:01:54.060
Was macht man damit überhaupt?

00:01:54.060 --> 00:01:58.860
Und also Django hört sich jetzt erstmal an, ja, was ist das, ein Tanz?

00:01:59.840 --> 00:02:03.060
Ja, es ist benannt nach einem Jazz-Gitarristen, Django Reinhardt.

00:02:04.540 --> 00:02:08.780
Die beiden Entwickler, die sich das ausgedacht haben, waren wohl Fans von diesem Gitarristen.

00:02:09.560 --> 00:02:14.440
Es hat sonst auch keinerlei Verbindung mehr dazu, nur der Name stammt daher.

00:02:15.060 --> 00:02:20.460
Django ist ein Framework, um Web-Anwendungen mit Python herstellen zu können.

00:02:20.460 --> 00:02:31.260
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?

00:02:32.680 --> 00:02:42.880
Ja, ich glaube, also 2005 ist es rausgekommen oder 2004, ich weiß nicht. Ich glaube, kurz nach Ruby on Rails. Und ich denke, das war auch so ein bisschen vielleicht das Vorbild für Django.

00:02:43.300 --> 00:02:50.260
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.

00:02:50.460 --> 00:03:03.520
Ich habe das damals kennengelernt von einer Veranstaltung, die hieß Snakes and Rubies. Sehr zu empfehlen auch übrigens. Gibt es auf YouTube immer noch das Video. Inzwischen ungeheuer alt. Wo sich eben da die beiden Hauptentwickler getroffen haben.

00:03:06.580 --> 00:03:08.840
Jacob Kaplan-Moss war das, glaube ich, der da war.

00:03:09.040 --> 00:03:12.160
Und der von Ruby on Rails heißt David Hanmeier-Hansen.

00:03:12.340 --> 00:03:12.980
Ja, genau.

00:03:13.180 --> 00:03:16.320
Und die beiden haben so im Wesentlichen ihre beiden Ansätze vorgestellt.

00:03:16.440 --> 00:03:19.640
Und haben eben Snakes und Rubys gezeigt.

00:03:19.980 --> 00:03:24.600
Und der eine, der Kaplan-Moss, hat eben gezeigt, wie man Probleme mit Django löst.

00:03:25.360 --> 00:03:27.200
So einmal quasi den Querschnitt.

00:03:27.320 --> 00:03:31.420
Wir haben eine Möglichkeit, URLs zu definieren und dann eine Funktionalität dazu zu definieren

00:03:31.420 --> 00:03:34.560
und dann die Templates dazu anzuzeigen und Sachen aus der Datenbank zu holen.

00:03:34.560 --> 00:03:39.660
Und dann hat der David Heinmeier-Hanson mehr oder weniger das Gleiche gemacht,

00:03:40.380 --> 00:03:43.800
aber auf eine ganz andere Art und Weise, eben auf die Ruby on Rails Art und Weise.

00:03:44.180 --> 00:03:47.920
Wodurch unterscheidet sich die Ruby on Rails Art und Weise von dem, was mir jetzt so...

00:03:47.920 --> 00:03:50.160
Ja, zuerst mal natürlich, dass es eine andere Programmiersprache ist.

00:03:52.000 --> 00:03:57.160
Aber Ruby on Rails geht wesentlich mehr über Konventionen.

00:03:57.940 --> 00:03:59.880
Bei Django wird sehr viel explizit gemacht.

00:04:00.080 --> 00:04:02.340
Also eines der Beispiele ist, wie eben URLs funktionieren.

00:04:02.640 --> 00:04:06.840
In Django definierst du eine URL, indem du einen regulären Ausdruck hinschreibst.

00:04:07.000 --> 00:04:10.480
Und wenn der reguläre Ausdruck eben dem entspricht, was der Benutzer in seinem Browser eingibt,

00:04:11.120 --> 00:04:12.880
dann wird die entsprechende Funktion dazu ausgeführt.

00:04:14.080 --> 00:04:15.380
In Ruby on Rails ist das anders.

00:04:15.480 --> 00:04:17.540
In Ruby on Rails ist das durch eine Konvention gemacht.

00:04:17.540 --> 00:04:19.800
Du hast einen Controller, der einen bestimmten Namen hat.

00:04:20.840 --> 00:04:27.260
Und über diesen Namen wird automatisch die URL bestimmt, über die du diesen Controller ansprechen kannst.

00:04:28.960 --> 00:04:32.580
Das heißt, du hast auf der einen Seite wesentlich stärkere Konventionen.

00:04:32.640 --> 00:04:38.480
Du hast damit die Möglichkeit, ein Ruby on Rails Projekt, sage ich mal, schneller zu verstehen, weil die alle die gleiche Struktur haben.

00:04:40.280 --> 00:04:43.060
Andererseits musst du diese Sachen eben wissen. Du musst die Konventionen wissen.

00:04:44.060 --> 00:04:47.240
Und das ist für mich so ein bisschen der große Unterschied am Anfang gewesen.

00:04:47.520 --> 00:05:02.360
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.

00:05:03.580 --> 00:05:04.440
Und das ist

00:05:04.440 --> 00:05:06.600
gleichzeitig eine Stärke und eine

00:05:06.600 --> 00:05:08.540
Schwäche, weil man eben

00:05:08.540 --> 00:05:10.440
dadurch in Ruby on Rails wesentlich

00:05:10.440 --> 00:05:12.500
schneller Ergebnisse sieht. Ich muss nur diesen

00:05:12.500 --> 00:05:14.300
Controller schreiben und ich muss ihm nur eben

00:05:14.300 --> 00:05:16.640
eine bestimmte Datei an die richtige Stelle hinlegen

00:05:16.640 --> 00:05:18.320
und dann wird das automatisch zu einer

00:05:18.320 --> 00:05:20.420
kompletten Webseite. In Django muss ich den ganzen

00:05:20.420 --> 00:05:22.580
Weg gehen. Ich muss die URL definieren, ich muss die Funktionalität

00:05:22.580 --> 00:05:24.560
definieren, ich muss die Datenbankmodelle definieren,

00:05:24.700 --> 00:05:26.320
ich muss die in die Datenbank

00:05:26.320 --> 00:05:28.380
reintun, ich muss die aus der Datenbank wieder rausholen

00:05:28.380 --> 00:05:30.440
und dann muss ich sie in ein Template reintun, was ich selbst

00:05:30.440 --> 00:05:31.620
definiert habe.

00:05:32.020 --> 00:05:34.020
Du hast ja gerade noch mal von Kontrollern geredet.

00:05:34.100 --> 00:05:36.100
Vielleicht weiß jetzt noch nicht jeder Hörer, was das genau ist.

00:05:36.700 --> 00:05:37.540
Wollt ihr das noch mal kurz erklären?

00:05:37.640 --> 00:05:40.040
Ich weiß nicht, Jochen hat es einmal mir schon ganz schön erklärt,

00:05:40.540 --> 00:05:41.120
um es dabei geht.

00:05:41.560 --> 00:05:43.540
Ja, also das wäre dann halt auch so eine Gemeinsamkeit

00:05:43.540 --> 00:05:45.300
zwischen Ruby on Rails und Django.

00:05:45.460 --> 00:05:48.960
Das sind beides so Model-View-Controller-Frameworks,

00:05:48.960 --> 00:05:52.980
also die diesen Ansatz halt halbwegs sauber irgendwie umsetzen.

00:05:53.120 --> 00:05:56.620
Das heißt, es gibt halt Modelle, in denen irgendwie definiert wird,

00:05:57.080 --> 00:05:59.760
wie die Daten aussehen, die man jetzt in der Applikation hält.

00:06:00.420 --> 00:06:05.840
also wie der State der Applikation quasi abgelegt ist, sich verhalten soll.

00:06:05.920 --> 00:06:08.060
Meistens hat man eine relationale Datenbank irgendwie im Hintergrund

00:06:08.060 --> 00:06:11.840
und dann muss halt aus den Modellen, wird dann halt ein Schema generiert

00:06:11.840 --> 00:06:14.060
und dann werden die Daten halt da irgendwie reingespeichert.

00:06:15.040 --> 00:06:21.560
Und dann hat man sogenannte Controller, die quasi die Daten, die in den Modellen sind,

00:06:21.560 --> 00:06:28.680
mit den Views, die halt dafür zuständig sind, wie das hinterher aussehen soll

00:06:28.680 --> 00:06:29.940
für ein Benutzerinterface

00:06:29.940 --> 00:06:32.480
verbinden sollen, wobei Benutzerinterface ganz

00:06:32.480 --> 00:06:33.900
unterschiedliche Sachen sein können, also

00:06:33.900 --> 00:06:36.620
ein Beispiel ist, man macht

00:06:36.620 --> 00:06:38.500
irgendwie ein Weltraumkampfspiel

00:06:38.500 --> 00:06:39.920
und dann gibt es halt

00:06:39.920 --> 00:06:42.800
vielleicht irgendwie ein grafisches Interface,

00:06:42.860 --> 00:06:44.540
wo man irgendwie die Raumschiffe rumfliegen sieht und so,

00:06:45.040 --> 00:06:46.380
aber man könnte sich halt auch vorstellen, dass ein

00:06:46.380 --> 00:06:48.640
anderes Interface nur textbasiert

00:06:48.640 --> 00:06:50.620
ist, wo sich dann Leute quasi per Telnet

00:06:50.620 --> 00:06:52.600
irgendwie einloggen oder so und

00:06:52.600 --> 00:06:54.620
das muss dann

00:06:54.620 --> 00:06:56.600
natürlich unterschiedlich aussehen, je nachdem

00:06:56.600 --> 00:06:58.380
was man für ein Interface hat oder

00:06:58.380 --> 00:07:00.320
wenn man jetzt ein Touch-Interface hat, ist es nochmal anders.

00:07:00.600 --> 00:07:02.420
Und dafür diese Unterschiede abzubilden,

00:07:02.460 --> 00:07:04.200
ist halt der View zuständig und der Controller.

00:07:05.560 --> 00:07:06.580
Die sind halt dafür da,

00:07:06.700 --> 00:07:08.460
sozusagen die Views mit den Modellen irgendwie

00:07:08.460 --> 00:07:10.560
zu verbinden, also die Daten irgendwie aus den Modellen zu holen,

00:07:10.660 --> 00:07:12.680
die dann in der Form den Views zu geben,

00:07:12.780 --> 00:07:14.480
wie sie das halt brauchen. Und ja, das

00:07:14.480 --> 00:07:15.860
Ganze nennt man irgendwie Model-View-Controller.

00:07:16.200 --> 00:07:18.400
Also Modell ist das, was in der Datenbank angelegt ist,

00:07:18.480 --> 00:07:20.420
wie dann das... Ja, aber auch die

00:07:20.420 --> 00:07:22.480
Objekte quasi, die hinterher in der Applikation

00:07:22.480 --> 00:07:24.380
sich um die Datenhaltung kümmern, sind auch

00:07:24.380 --> 00:07:26.400
sozusagen die Modelle, ja.

00:07:26.720 --> 00:07:28.200
Okay. Also Datenbank ist halt

00:07:28.200 --> 00:07:30.160
eigentlich nochmal ein Parallel. Also die Klassen, die man benutzt

00:07:30.160 --> 00:07:31.640
zur Verwaltung von dieser Datenbank auch.

00:07:32.240 --> 00:07:34.180
Ja, ja, genau, genau. Und was

00:07:34.180 --> 00:07:36.200
ein bisschen verwirrend ist, ist halt, dass

00:07:36.200 --> 00:07:38.400
in den Django die Views Templates

00:07:38.400 --> 00:07:40.200
heißen und die Controller Views

00:07:40.200 --> 00:07:42.100
das, äh, weiß nicht,

00:07:42.200 --> 00:07:44.360
ein bisschen... Ihr seid ja alle ein bisschen

00:07:44.360 --> 00:07:45.420
verwirrt und durcheinander, okay.

00:07:46.200 --> 00:07:48.260
Ja, da stolpern Anfänger oft

00:07:48.260 --> 00:07:50.180
drüber, dass die Bezeichnungen anders sind und eben

00:07:50.180 --> 00:07:51.500
ausgerechnet View und View

00:07:51.500 --> 00:07:53.820
unterschiedliche Dinge bedeuten.

00:07:54.060 --> 00:07:56.260
Gemein, da muss doch jemand mal so ein Request stellen und sagen,

00:07:56.360 --> 00:07:57.840
hey, ändert das mal. Ja, aber

00:07:57.840 --> 00:08:00.280
nach über zehn Jahren ist das halt ein bisschen schwer zu ändern.

00:08:00.660 --> 00:08:01.720
Das geht halt nicht mehr so richtig gut.

00:08:01.740 --> 00:08:03.760
Da haben sich dann die anderen Leute auch dran gewöhnt, wie das dann heißt.

00:08:03.920 --> 00:08:04.300
Ja, verstehe.

00:08:05.640 --> 00:08:07.800
Ja, also wofür nutzt man denn Dango, wenn ihr jetzt

00:08:07.800 --> 00:08:10.140
gesagt habt, was da schon man mit machen kann?

00:08:12.140 --> 00:08:14.100
Ja, im Prinzip kann man jede

00:08:14.100 --> 00:08:16.240
Web-Anwendung damit

00:08:16.240 --> 00:08:17.800
herstellen.

00:08:18.500 --> 00:08:20.200
Und die Breite ist da,

00:08:20.200 --> 00:08:22.080
also es gibt

00:08:22.080 --> 00:08:23.200
quasi keine Begrenzung.

00:08:23.820 --> 00:08:26.160
Die erste Anwendung, die sicherlich jeder machen muss, ist ein Blog

00:08:26.160 --> 00:08:32.940
Und jeder Django-Entwickler, der mehr als ein halbes Jahr daran gearbeitet hat, hat auch schon mal einen Blog damit gemacht.

00:08:34.160 --> 00:08:39.340
Dann gibt es so die ganz typischen Sachen, den Wiki-Programmieren einfach mal auch zur Übung.

00:08:41.020 --> 00:08:48.540
Ich mache regelmäßig Django-Kurse und da programmieren wir dann Shops nach oder eBay nachprogrammiert oder Twitter nachprogrammiert,

00:08:48.680 --> 00:08:53.160
einfach um zu sehen, wie solche Funktionalitäten in Web-Anwendungen umgesetzt werden.

00:08:53.560 --> 00:09:10.980
Und in einem einwöchigen Kurs ist es absolut kein Problem, eine Basisfunktion von jeder dieser Webseiten hinzukriegen. Klar, die sehen nicht so schön aus und die haben auch nicht so viele Funktionen wie die tatsächlichen Vorbilder, aber die Grundvorgangsqualität ist eben sehr schnell damit umzusetzen.

00:09:10.980 --> 00:09:15.700
Auf was konzentrierst du dich dann besonders in diesem Kurs? Also auf das Model, das View, das Controller-Ding?

00:09:15.700 --> 00:09:39.680
Nee, die müssen alle drei zusammenarbeiten, weil du mit jedem dieser Teile allein hast du keine komplette Anwendung. Es wird erst dann eine komplette Anwendung, wenn die drei zusammenarbeiten. Das heißt, man muss so zwischen diesen Bereichen hin und her springen und da gibt es auch verschiedene Möglichkeiten, damit umzugehen, die sich auch, gerade wenn man mit anderen Leuten darüber spricht, zeigen, dass da jeder unterschiedlich damit umgeht.

00:09:40.700 --> 00:09:58.380
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.

00:09:58.580 --> 00:10:03.400
Ich brauche irgendwelche Sachen, die ich anzeigen kann, weil im Endeffekt eine Webseite daraus werden soll.

00:10:03.440 --> 00:10:08.080
Das heißt, ich brauche so ein Template oder in der klassischen Sprache, ich brauche einen View.

00:10:09.040 --> 00:10:13.460
Und ich brauche irgendwas, was eine Funktionalität darstellt, weil sonst macht meine Web-Anwendung nichts.

00:10:13.600 --> 00:10:16.660
Und das ist hier in Django eben der Controller bzw. die View-Funktion.

00:10:17.760 --> 00:10:25.120
Nur wenn ich diese drei Teile zusammen habe und wenn die drei Teile so ineinander greifen, dass sie zusammen funktionieren, wird daraus eine Web-Anwendung.

00:10:25.500 --> 00:10:37.780
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.

00:10:39.900 --> 00:10:41.380
Klingt praktisch.

00:10:42.560 --> 00:10:52.680
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.

00:10:52.680 --> 00:10:54.620
Also Django Admin ist das Backend-Interface,

00:10:54.720 --> 00:10:56.340
um seine Seite zu daten. Genau, das ist sozusagen

00:10:56.340 --> 00:10:58.680
ein genialer Zaubertrick, weil

00:10:58.680 --> 00:11:00.760
der Django Admin, das ist einfach

00:11:00.760 --> 00:11:01.600
ein Modul in Django.

00:11:02.420 --> 00:11:04.740
Und ich kann das reinladen, das hat eine URL, wie alles andere

00:11:04.740 --> 00:11:06.740
auch. Aber was der

00:11:06.740 --> 00:11:08.800
machen kann, ist, der kann die Modelle,

00:11:08.840 --> 00:11:10.640
die ich geschrieben habe, inspizieren und mir die dann

00:11:10.640 --> 00:11:12.560
eben in einer schönen Darstellung zeigen.

00:11:14.340 --> 00:11:14.780
Das heißt,

00:11:15.000 --> 00:11:16.160
ich habe automatisch

00:11:16.160 --> 00:11:18.540
eine Backend-Funktionalität drin,

00:11:18.600 --> 00:11:20.540
ich habe automatisch eine Verwaltungsfunktion drin,

00:11:20.740 --> 00:11:22.620
die aber meine Modellierung

00:11:22.620 --> 00:11:24.560
nimmt. Das heißt, die

00:11:24.560 --> 00:11:26.400
sich auf meine Modellklassen

00:11:26.400 --> 00:11:27.740
bezieht und die mir

00:11:27.740 --> 00:11:30.520
das Schreiben von so einer Backend-Funktionalität

00:11:30.520 --> 00:11:32.620
im Wesentlichen wegnimmt.

00:11:33.380 --> 00:11:34.580
Und das

00:11:34.580 --> 00:11:36.460
ist eine sehr schöne Sache, wenn man eben so eine

00:11:36.460 --> 00:11:38.500
Anwendung zum ersten Mal schreibt und sagt,

00:11:38.600 --> 00:11:40.700
okay, ich habe mich jetzt an WordPress orientiert,

00:11:40.780 --> 00:11:42.580
ich möchte einen Blog machen. Jeder möchte einen Blog machen

00:11:42.580 --> 00:11:42.860
am Anfang.

00:11:44.880 --> 00:11:46.560
Dann gehört dazu eben auch so

00:11:46.560 --> 00:11:48.620
ein Interface, wo ich die Blogposts bearbeiten

00:11:48.620 --> 00:11:49.240
kann.

00:11:51.100 --> 00:11:51.800
Und das

00:11:51.800 --> 00:12:06.680
In der ersten Version kann man das sicherlich im Django-Admin einfach drin lassen, weil es da die Möglichkeit gibt, Seiten hinzuzufügen und Seiten zu bearbeiten und Seiten zu löschen und vielleicht Seiten, keine Ahnung, wenn man das modelliert hat, freizugeben oder irgendwo hinzuverschieben oder sonst was zu machen.

00:12:06.840 --> 00:12:36.060
Diese ganzen Basisfunktionalitäten, die man immer braucht, die sind im Django-Admin schon drin. Das heißt oft CRUD, Create, Read, Update, Delete. Das sind die vier Funktionen, die man immer mit seinen Datenbank-Dingen tun muss und die sind eben schon im Django-Admin drin und das ist einfach eine sehr praktische Sache, weil diese drei Teile Model-View und Controller so gut integriert sind, dass man quasi aus Django heraus die zusätzlichen Dinge da mit reinnehmen kann.

00:12:36.060 --> 00:12:38.320
Ist das bei Django ganz individuell

00:12:38.320 --> 00:12:40.260
oder einzigartig? Oder machen das die anderen Frameworks,

00:12:40.380 --> 00:12:41.360
die es in Python oder so gibt,

00:12:41.780 --> 00:12:43.820
von Flask oder von Pyramid mal gehört,

00:12:44.400 --> 00:12:44.740
auch so?

00:12:45.300 --> 00:12:48.180
Ja, gut, es gibt auch noch andere, die das auch so machen.

00:12:48.760 --> 00:12:50.300
Aber ich würde sagen,

00:12:50.400 --> 00:12:52.120
die Bekannteren, die das halt komplett

00:12:52.120 --> 00:12:54.300
integrieren, sind eben Django für Python

00:12:54.300 --> 00:12:56.220
oder halt eben Ruby und Rails für Ruby.

00:12:57.080 --> 00:12:58.060
Und wenn man jetzt

00:12:58.060 --> 00:12:59.880
zum Beispiel Flask nimmt, dann ist das eher

00:12:59.880 --> 00:13:01.700
ein etwas anderer Ansatz. Da ist es halt so,

00:13:02.200 --> 00:13:02.700
dass der

00:13:02.700 --> 00:13:05.880
Layer, also Flask selber

00:13:05.880 --> 00:13:06.880
enthält kaum

00:13:06.880 --> 00:13:10.160
Model-View-Controller-Funktionalität,

00:13:10.240 --> 00:13:11.860
wie man sonst so in Django hat. Also es ist halt nicht

00:13:11.860 --> 00:13:12.740
alles integriert, sondern

00:13:12.740 --> 00:13:15.200
da kann man sich halt

00:13:15.200 --> 00:13:17.980
Dinge zusammenstecken,

00:13:18.040 --> 00:13:19.560
die man benutzen kann. Zum Beispiel der

00:13:19.560 --> 00:13:21.980
Object

00:13:21.980 --> 00:13:23.020
Relational Mapper,

00:13:23.640 --> 00:13:25.620
ORM genannt oft,

00:13:26.440 --> 00:13:27.860
ist halt in Flask

00:13:27.860 --> 00:13:29.880
meistens SQL Alchemy. Man kann aber auch irgendwas anderes

00:13:29.880 --> 00:13:31.180
nehmen. Man kann, wie heißt dieses Dings,

00:13:31.480 --> 00:13:33.500
Pony oder so, was da irgendwie heute

00:13:33.500 --> 00:13:35.560
irgendwie recht beliebt ist, nehmen

00:13:35.560 --> 00:13:37.480
oder so. Man könnte auch den

00:13:37.480 --> 00:13:39.480
Django-ORM nehmen. Man könnte auch den Django, genau.

00:13:39.640 --> 00:13:41.480
OR was? ORM

00:13:41.480 --> 00:13:43.040
Object Relation Mapper.

00:13:43.560 --> 00:13:45.360
Das ist die Verbindung zwischen der

00:13:45.360 --> 00:13:47.500
SQL-Datenbank, die eben

00:13:47.500 --> 00:13:49.300
rohes SQL braucht und

00:13:49.300 --> 00:13:51.400
der Python-Welt, wo wir ja mit Python-Klassen

00:13:51.400 --> 00:13:53.420
arbeiten. Okay, jetzt habe ich das verstanden.

00:13:54.300 --> 00:13:55.560
Ja, und

00:13:55.560 --> 00:13:57.500
genau, bei Flask ist halt der

00:13:57.500 --> 00:13:59.560
Vorteil, dass man sich da quasi die

00:13:59.560 --> 00:14:01.500
Dinge, die man vielleicht auch sonst verwendet oder die man

00:14:01.500 --> 00:14:03.060
lieber mag, irgendwie benutzen kann.

00:14:03.500 --> 00:14:06.340
Während bei Django kann man das theoretisch auch.

00:14:06.420 --> 00:14:08.280
Mit manchen Dingen ist es einfacher als mit anderen.

00:14:08.760 --> 00:14:11.800
Aber ich würde es jetzt nicht unbedingt gerade empfehlen.

00:14:12.160 --> 00:14:15.280
Den Django-ORM auszutauschen ist halt ...

00:14:15.280 --> 00:14:16.600
Ja, kann sein, dass das geht,

00:14:16.760 --> 00:14:18.920
aber das will man wahrscheinlich eher nicht tun.

00:14:19.360 --> 00:14:22.180
Bevor man das macht, nimmt man dann vielleicht auch besser Flask oder so.

00:14:23.120 --> 00:14:24.780
Und ja, das sind halt unterschiedliche Trade-offs.

00:14:24.880 --> 00:14:27.020
Das hat halt gewisse Vorteile, wenn alles integriert ist.

00:14:27.760 --> 00:14:29.200
Und es hat halt auch gewisse Nachteile.

00:14:29.300 --> 00:14:30.820
Es ist halt ein bisschen weniger Flexibilität.

00:14:31.480 --> 00:14:33.740
Es ist eine steilere Lernkurve am Anfang,

00:14:34.460 --> 00:14:37.340
aber weil einfach viel mehr Funktionalität da ist,

00:14:37.480 --> 00:14:39.460
mit der man irgendwie sich vertraut machen muss.

00:14:40.120 --> 00:14:43.580
Aber wenn man da erstmal so durchgestiegen ist,

00:14:43.660 --> 00:14:46.020
dann ist es halt auch schneller, damit irgendwas zu machen

00:14:46.020 --> 00:14:48.700
oder das halt auf neue Anforderungen anzupassen,

00:14:48.700 --> 00:14:51.100
als wenn man das jetzt irgendwie immer neu zusammenstöpseln muss.

00:14:51.800 --> 00:14:54.740
Wie ist das denn zum Beispiel, wenn du jetzt so ein Modul benutzt,

00:14:54.800 --> 00:14:55.620
was es irgendwie schon gibt,

00:14:56.100 --> 00:14:57.220
wie viel Arbeit wäre das denn jetzt,

00:14:57.300 --> 00:14:58.800
in so ein neues Framework zu integrieren?

00:15:00.600 --> 00:15:02.160
Das kommt total auf das Modul

00:15:02.160 --> 00:15:03.860
an. Das kann man so,

00:15:03.960 --> 00:15:05.580
diese Fragen kann man so eigentlich nicht beantworten.

00:15:06.740 --> 00:15:06.960
Die

00:15:06.960 --> 00:15:10.380
Mentalität,

00:15:10.380 --> 00:15:12.420
glaube ich, zwischen diesen Frameworks ist auch so ein bisschen

00:15:12.420 --> 00:15:14.080
unterschiedlich. Flask ist so ein bisschen,

00:15:14.360 --> 00:15:15.740
du kannst alles benutzen, was du willst.

00:15:16.440 --> 00:15:18.400
Du musst dann halt selber dafür sorgen, dass die Teile

00:15:18.400 --> 00:15:20.380
zusammenpassen. Und Django ist

00:15:20.380 --> 00:15:22.320
mehr so ein bisschen, hier, wir haben

00:15:22.320 --> 00:15:24.420
den Bausatz gemacht und du kannst gerne darauf aufbauen,

00:15:24.520 --> 00:15:25.980
aber die müssen so funktionieren, wie wir das

00:15:25.980 --> 00:15:27.580
vorgegeben haben.

00:15:29.040 --> 00:15:30.340
Das heißt eben, wenn ich eine

00:15:30.340 --> 00:15:32.920
Modul habe oder eine Bibliothek, die

00:15:32.920 --> 00:15:34.860
nicht integriert ist, dann bin ich in Flask

00:15:34.860 --> 00:15:36.840
sicherlich schneller damit unterwegs, weil ich dann eben

00:15:36.840 --> 00:15:38.420
sowieso für diese Anbindung sorgen muss.

00:15:39.680 --> 00:15:40.860
In Django ist es dann eben

00:15:40.860 --> 00:15:42.780
oft so, dass es schon eine Django-Variante

00:15:42.780 --> 00:15:44.740
gibt davon, die mir

00:15:44.740 --> 00:15:46.760
eben genau diese Integration schon gibt. Und dann

00:15:46.760 --> 00:15:48.780
ist es natürlich leichter, die

00:15:48.780 --> 00:15:49.840
Django-Variante zu verwenden.

00:15:50.720 --> 00:15:52.640
Heißt halt aber, dass ich darauf angewiesen bin, dass

00:15:52.640 --> 00:15:54.700
schon jemand die Arbeit gemacht hat und auch

00:15:54.700 --> 00:15:56.380
fortlaufen tut, weil die Versionen

00:15:56.380 --> 00:15:58.700
natürlich ständig aktualisiert

00:15:58.700 --> 00:15:59.500
werden und

00:15:59.500 --> 00:16:02.380
es hat alles so seine

00:16:02.380 --> 00:16:03.100
Vor- und Nachteile.

00:16:04.620 --> 00:16:06.420
Wie würdet ihr denn einsteigen, wenn

00:16:06.420 --> 00:16:08.620
jetzt irgendwie jemand, der das noch nie gemacht

00:16:08.620 --> 00:16:10.580
hat, möchte seine erste Website, einen Blog

00:16:10.580 --> 00:16:12.560
einstellen, was würdet ihr ihm empfehlen? Einfach

00:16:12.560 --> 00:16:14.580
das Paket installieren und Tutorial

00:16:14.580 --> 00:16:16.580
lesen oder gibt es da schon eine Best Practice, wo

00:16:16.580 --> 00:16:18.620
ihr am besten...

00:16:19.440 --> 00:16:20.540
Ja, also ich würde,

00:16:20.740 --> 00:16:22.480
das habe ich bisher dann auch immer so gemacht, wenn ich

00:16:22.480 --> 00:16:23.680
das gefragt worden bin,

00:16:24.600 --> 00:16:26.380
das Two Scoops auf Django

00:16:26.380 --> 00:16:28.280
Buch zu empfehlen. Also das jetzt

00:16:28.280 --> 00:16:29.840
ist halt momentan nicht mehr so richtig super aktuell.

00:16:30.100 --> 00:16:30.680
Ich glaube, die letzte

00:16:30.680 --> 00:16:33.980
Auflage ist für Django 1.11

00:16:33.980 --> 00:16:36.220
und wir sind jetzt aber auch eigentlich schon bei 2.1.

00:16:37.660 --> 00:16:38.300
Da kommt

00:16:38.300 --> 00:16:39.540
dann wahrscheinlich für die nächste stabile

00:16:39.540 --> 00:16:41.740
oder länger

00:16:41.740 --> 00:16:44.100
supportete Release von Django wahrscheinlich

00:16:44.100 --> 00:16:45.920
auch wieder eine neue Version. Aber

00:16:45.920 --> 00:16:48.300
da wird eigentlich mal so grob beschrieben,

00:16:48.420 --> 00:16:49.860
wie man Dinge tut mit Django

00:16:49.860 --> 00:16:51.600
und so, ja.

00:16:53.260 --> 00:16:54.120
Also ich fand das,

00:16:54.120 --> 00:16:55.700
ich habe damals auch quasi

00:16:55.700 --> 00:16:57.820
einen Einstieg in Django über dieses Buch

00:16:57.820 --> 00:17:00.000
gefunden, das war irgendwann 2013

00:17:00.000 --> 00:17:01.760
oder so, weil ich irgendwie ein Projekt

00:17:01.760 --> 00:17:04.100
plötzlich mit einem Django-Backend konfrontiert war

00:17:04.100 --> 00:17:05.200
und dann, ja,

00:17:06.600 --> 00:17:08.020
mir auch gesagt wurde,

00:17:08.160 --> 00:17:09.680
dann liest doch mal einfach dieses Buch und dann

00:17:09.680 --> 00:17:11.960
macht alles Sinn plötzlich.

00:17:12.940 --> 00:17:14.100
Und so ein bisschen war das

00:17:14.100 --> 00:17:15.020
schon so. Also das war

00:17:15.020 --> 00:17:18.180
sehr, sehr hilfreich.

00:17:19.180 --> 00:17:19.980
Ja, man kann aber auch mit

00:17:19.980 --> 00:17:22.060
der Dokumentation, die sehr gut ist, anfangen

00:17:22.060 --> 00:17:23.940
oder ich weiß nicht, vielleicht mit einem von

00:17:23.940 --> 00:17:24.640
Johannes Krosen.

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

00:17:42.480 --> 00:17:50.140
Ich meine, es ist nicht schlecht. Ja, und die Leute, die das machen, sind auch Experten und wir benutzen auch sehr viel davon. Wir werden vielleicht noch über Cookie Cutter sprechen.

00:17:52.300 --> 00:17:54.560
Aber ich finde, es hat schon zu viel Flavor.

00:17:54.560 --> 00:17:59.620
Es ist schon zu weit von Vanilla Django weg.

00:18:00.180 --> 00:18:01.560
Das sind ja noch mehr Freiheiten,

00:18:01.720 --> 00:18:03.580
die du selber gerne kreativ ausleben würdest,

00:18:03.660 --> 00:18:05.260
wenn du genau verstanden hättest, wie es funktioniert.

00:18:05.440 --> 00:18:07.100
Genau, und das bedeutet auch,

00:18:07.200 --> 00:18:10.040
dass man eben auf diese Wahl festgelegt ist,

00:18:10.140 --> 00:18:14.000
die die Leute von Two Scopes of Django schon getroffen haben für uns.

00:18:14.220 --> 00:18:16.620
Weil die eben, wie gesagt, ihre Meinungen haben

00:18:16.620 --> 00:18:17.640
und weil die sagen, okay,

00:18:17.680 --> 00:18:20.340
du solltest eigentlich immer diese bestimmten Systeme verwenden

00:18:20.340 --> 00:18:21.280
und eben nicht diese anderen.

00:18:22.240 --> 00:18:25.580
Hast du das schon getan, so ein Beispiel?

00:18:26.820 --> 00:18:27.720
Ja, zum Beispiel, wenn

00:18:27.720 --> 00:18:29.560
die ihre Docker-Container

00:18:29.560 --> 00:18:31.800
bereitstellen. Es gibt oft

00:18:31.800 --> 00:18:33.760
Situationen, wo man eben keine Docker-Container haben

00:18:33.760 --> 00:18:35.820
möchte. Das ist halt aber bei

00:18:35.820 --> 00:18:37.440
denen einfach so. Die haben alles dockerisiert.

00:18:38.820 --> 00:18:39.900
Ist einfach so eine Sache.

00:18:40.040 --> 00:18:41.760
Oder die benutzen Django-Crispy-Forms,

00:18:42.620 --> 00:18:43.260
wo ich

00:18:43.260 --> 00:18:45.600
am Anfang sehr damit zu kämpfen hatte,

00:18:45.800 --> 00:18:47.580
weil es gar nicht dem entspricht, wie ich das mache.

00:18:47.760 --> 00:18:49.420
Das müssen wir vielleicht gleich nochmal kurz erklären, was ein

00:18:49.420 --> 00:18:51.420
Docker-Container ist und was eine Crispy-Form ist.

00:18:51.960 --> 00:19:01.440
Das sind einfach nur so zwei Beispiele, wo Two Scoops of Django schon was ausgewählt hat, was man eventuell anders machen würde.

00:19:02.440 --> 00:19:05.140
Unwichtig, was das jetzt genau bedeutet oder was das jetzt genau ist.

00:19:06.020 --> 00:19:14.320
Ich fange üblicherweise mit dem Tutorial an auf der Webseite, weil es zum einen relativ gut geschrieben ist.

00:19:15.200 --> 00:19:18.420
Die Django-Dokumentation ist erstklassig, die ist einwandfrei, die ist super.

00:19:20.540 --> 00:19:21.760
Kann ich jedem nur empfehlen.

00:19:22.180 --> 00:19:24.660
Auch wenn man nur die Django-Dokumentation liest

00:19:24.660 --> 00:19:26.580
und das alles mehrmals angeschaut hat,

00:19:26.720 --> 00:19:28.600
dann ist man Experte in Django-Entwicklung.

00:19:29.580 --> 00:19:31.880
Und das Tutorial ist einfach ein schneller Einstieg

00:19:31.880 --> 00:19:36.160
in was muss ich tun, um eine Funktionalität zu kriegen.

00:19:37.540 --> 00:19:39.940
Aber eigentlich würde ich noch einen Schritt vorher anfangen.

00:19:39.940 --> 00:19:42.280
Wenn sich jemand da einlesen möchte,

00:19:43.380 --> 00:19:45.960
oder wenn jemand anfangen möchte, mit Django zu programmieren,

00:19:46.640 --> 00:19:48.760
ist meine Empfehlung, immer erst mal einen Schritt zurückzugehen

00:19:48.760 --> 00:19:51.140
und zu überlegen genau, was man eigentlich erreichen möchte.

00:19:52.360 --> 00:19:55.580
Weil es oft schwierig ist, das gleichzeitig zu machen,

00:19:55.700 --> 00:19:59.880
gleichzeitig zu lernen, wie man etwas erreicht

00:19:59.880 --> 00:20:03.100
und herauszufinden, was man eigentlich erreichen möchte.

00:20:03.340 --> 00:20:04.840
Das heißt, du würdest dir ein Projekt ausdenken,

00:20:04.960 --> 00:20:06.700
was derjenige dann umsetzen möchte,

00:20:06.820 --> 00:20:08.560
ob es jetzt Freizeit ist oder irgendwie nebenbei

00:20:08.560 --> 00:20:10.020
oder schon was Professionelles

00:20:10.020 --> 00:20:11.920
und dann direkt an dem Projekt konkret

00:20:11.920 --> 00:20:14.480
sich die Lösung aus Django dann zu erarbeiten.

00:20:14.720 --> 00:20:16.740
Genau, und vielleicht auch einfach mal konkret zu sagen,

00:20:16.740 --> 00:20:21.040
was muss ich haben an Funktionalität, um mein Ziel erreicht zu haben.

00:20:22.060 --> 00:20:24.740
Machst du das dann richtig mit Stift und Papier oder auf einem Whiteboard

00:20:24.740 --> 00:20:26.540
oder malst du da eine Kreidetafel voll?

00:20:26.800 --> 00:20:31.360
Je nachdem, wo ich gerade bin und was gerade für Werkzeuge da sind.

00:20:31.760 --> 00:20:35.240
Wenn ich nur einen Texteditor da habe, dann schreibe ich mir halt ein paar Punkte im Texteditor rein.

00:20:35.320 --> 00:20:39.060
Wenn ich die Wachsmalstifte von meinem Kleidung dabei habe, dann male ich mir was auf die Hand.

00:20:39.480 --> 00:20:43.640
Nee, es ist einfach nur wichtig, ein Bild davon zu haben, was man erreichen möchte.

00:20:43.640 --> 00:20:46.460
Zu wissen, wo möchte ich hinkommen?

00:20:46.740 --> 00:21:03.800
Oder soll das ein Blog sein, was YouTube-Videos anzeigt? Oder soll das ein Podcast-Blog sein? Oder soll das ein Blog sein, wo ich nur, keine Ahnung, meine Texte reinschreibe? Müssen da Bilder rein? Müssen da andere Dateitypen rein? Will ich Sharing-Buttons haben?

00:21:04.020 --> 00:21:21.160
Laute so Sachen, die jeder für sich entscheiden muss, die jeder für dieses Projekt entscheiden muss und die sicherlich in jedem Projekt anders sein werden, die aber eben dazu führen, dass man während man daran arbeitet, nicht mehr so viel drüber nachdenken muss. Und das ist für mich eine ganz wichtige Sache, dass ich eben weiß, wo ich hin möchte.

00:21:22.080 --> 00:21:39.520
Das kann sich zwischendurch ja ruhig ändern. Man muss ja seinen Weg auch anpassen können. Und wenn man sich eben herausstellt, dass man sich zu viel vorgenommen hat oder dass das, was man sich vorgenommen hat, nicht erreichbar ist oder dass es zu schwer ist, dann muss man das vielleicht anders machen.

00:21:39.520 --> 00:21:55.440
Aber man sollte trotzdem immer wissen, wo man hin möchte, weil wenn man dann anfängt, tatsächlich diese Umsetzung zu machen, ist man so sehr damit beschäftigt, die Dinge zu lernen, die man wissen muss, dass es schwer ist, sich Gedanken darüber zu machen, ob das überhaupt sinnvoll ist, was man jetzt sagt.

00:21:55.480 --> 00:22:05.540
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?

00:22:05.540 --> 00:22:20.580
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.

00:22:20.580 --> 00:22:43.360
Da braucht man halt möglicherweise noch eine Anbindung an Cash-Backend-Redis oder sowas. Man braucht vielleicht irgendwie eine Volltext-Suchmaschine, die man dann auch noch drin hat. Man hat vielleicht irgendwelche Background-Tasks, die laufen müssen und so weiter und so weiter. Da gibt es noch eine ganze Menge Dinge, die man halt irgendwie einstellen muss und wo man Entscheidungen treffen muss.

00:22:43.800 --> 00:23:09.780
Und das ist doch relativ überwältigend, denke ich mal, für jemanden, der eigentlich nur mal einen Blog schreiben wollte und mal schnell irgendwie eine Django-App hochziehen wollte und da gibt es dann halt so ein Tool, nennt sich Cookie Cutter, das ist auch von den Autoren von Two Scoops of Django oder beziehungsweise von einer der beiden Autoren und das legt dann halt so ein Projekt quasi an.

00:23:09.780 --> 00:23:11.700
Da werden einem am Anfang im Grunde

00:23:11.700 --> 00:23:13.680
genau so ein paar dieser Fragen gestellt, halt so

00:23:13.680 --> 00:23:15.140
möchtest du Docker oder lieber nicht oder

00:23:15.140 --> 00:23:17.720
brauchst du eigentlich Hintergrund-Tasks wirklich

00:23:17.720 --> 00:23:19.420
und

00:23:19.420 --> 00:23:21.340
wenn man das angegeben hat, dann

00:23:21.340 --> 00:23:23.600
wird quasi aus den, wenn halt

00:23:23.600 --> 00:23:25.660
die Template-Variablen, die

00:23:25.660 --> 00:23:27.540
im Projekt-Template drin sind, ersetzt

00:23:27.540 --> 00:23:29.700
durch konkrete Werte, also man gibt dem Projekt halt einen Namen

00:23:29.700 --> 00:23:31.540
und so, der wird dann relativ oft eingetragen

00:23:31.540 --> 00:23:32.940
und dann wird halt so ein Projekt erstellt

00:23:32.940 --> 00:23:35.600
und das läuft dann halt auch direkt von Anfang

00:23:35.600 --> 00:23:35.860
an.

00:23:37.300 --> 00:23:39.520
Und damit hat man dann ja quasi schon mal

00:23:39.520 --> 00:23:40.240
einen großen Schritt

00:23:40.240 --> 00:23:42.420
geschafft,

00:23:43.140 --> 00:23:45.580
weil bis dahin zu kommen möglicherweise

00:23:45.580 --> 00:23:47.140
auf anderem Weg relativ

00:23:47.140 --> 00:23:49.460
lange dauern könnte. Auf der anderen Seite

00:23:49.460 --> 00:23:51.460
hat man natürlich das Problem, dass man nicht genau weiß, was passiert

00:23:51.460 --> 00:23:53.020
ist und man halt jetzt auch viele

00:23:53.020 --> 00:23:55.560
sozusagen Einstellungen

00:23:55.560 --> 00:23:57.340
schon vorgenommen sind, von denen man jetzt

00:23:57.340 --> 00:23:59.260
gar nicht genau weiß, ob man die wirklich so haben

00:23:59.260 --> 00:24:01.140
wollte oder nicht und

00:24:01.140 --> 00:24:02.620
ja, man

00:24:02.620 --> 00:24:05.180
die man auch nur noch schwer ändern kann

00:24:05.180 --> 00:24:07.060
und man versteht nicht so genau, was da passiert

00:24:07.060 --> 00:24:09.180
und das ist natürlich in gewisser

00:24:09.180 --> 00:24:11.160
so ein Nachteil. Also, aber es ist

00:24:11.160 --> 00:24:13.160
denke ich schon halt irgendwie eine

00:24:13.160 --> 00:24:15.100
Möglichkeit, relativ schnell zu einem

00:24:15.100 --> 00:24:16.320
funktionierenden System zu kommen.

00:24:17.420 --> 00:24:19.320
Und ja, darauf aufbauen

00:24:19.320 --> 00:24:20.840
kann man dann ja weitermachen. Aber ja,

00:24:22.480 --> 00:24:23.360
es kann einem eine Menge

00:24:23.360 --> 00:24:25.200
Arbeit ersparen. Ich mache das meistens so, wenn

00:24:25.200 --> 00:24:27.080
ich neue Projekte irgendwie aufmache, dass ich halt

00:24:27.080 --> 00:24:29.280
dann irgendwie das Django-Cookie-Cutter-Template

00:24:29.280 --> 00:24:31.040
benutze. Aber ja,

00:24:31.200 --> 00:24:33.080
das trifft dann natürlich schon eine

00:24:33.080 --> 00:24:34.620
ganze Menge Entscheidungen,

00:24:35.080 --> 00:24:36.640
die man vielleicht auch anders treffen können wollte.

00:24:39.180 --> 00:24:41.920
Klingt aber, als könnte man es gut gebrauchen

00:24:41.920 --> 00:24:43.820
für Projekte, bei denen man schon

00:24:43.820 --> 00:24:45.160
relativ genau weiß, was man will.

00:24:46.680 --> 00:24:46.920
Ja.

00:24:48.000 --> 00:24:49.400
Naja, also ich meine, ich

00:24:49.400 --> 00:24:51.880
habe, das ist halt dann die Frage, ob man

00:24:51.880 --> 00:24:53.660
sozusagen

00:24:53.660 --> 00:24:55.840
das, was man tun möchte, den eigenen

00:24:55.840 --> 00:24:57.940
Bedürfnissen anpasst oder die eigenen Bedürfnisse halt so

00:24:57.940 --> 00:24:59.940
ähnlich wie eine SAP-Einführung.

00:25:00.280 --> 00:25:01.540
Also quasi, wenn man

00:25:01.540 --> 00:25:03.900
sich dafür entscheidet, das zu verwenden, dann muss man

00:25:03.900 --> 00:25:05.940
halt die eigenen Prozesse so umstellen, dass sie zu SAP passen

00:25:05.940 --> 00:25:07.940
und dann geht das halbwegs. Und bei Cookie Cutter ist es

00:25:07.940 --> 00:25:09.840
halt auch so, man muss dann die Dinge so

00:25:09.840 --> 00:25:12.080
machen, wie dieses Template das halt irgendwie quasi

00:25:12.080 --> 00:25:14.080
vorgibt.

00:25:14.760 --> 00:25:15.840
Und wenn man das anders machen will,

00:25:15.900 --> 00:25:17.680
hat man Schwierigkeiten oder

00:25:17.680 --> 00:25:20.040
dann ist es halt nicht mehr so hilfreich, weil dann muss man wieder eine ganze Menge

00:25:20.040 --> 00:25:21.800
von Hand ändern, was man ja eigentlich vermeiden

00:25:21.800 --> 00:25:22.960
wollte, indem man Cookie-Catter verwendet.

00:25:24.700 --> 00:25:25.620
Es ist halt so eine,

00:25:25.920 --> 00:25:27.820
also wenn man sich quasi damit abfindet, dass alles

00:25:27.820 --> 00:25:29.640
so ist, wie das in dem Template halt

00:25:29.640 --> 00:25:31.860
vorgesehen ist, dann ist es eigentlich

00:25:31.860 --> 00:25:33.820
ganz nett. Also dann, wenn man das

00:25:33.820 --> 00:25:35.340
nicht so toll findet, dann

00:25:35.340 --> 00:25:37.660
hilft es einem halt nicht. Dann muss man vielleicht ein eigenes Template machen.

00:25:37.940 --> 00:25:41.220
Viele Sachen, die in dem Cookie-Cutter-Template

00:25:41.220 --> 00:25:42.900
drin sind, gehen für mich

00:25:42.900 --> 00:25:44.920
so ein bisschen in Richtung Produktivbetrieb.

00:25:45.600 --> 00:25:46.980
Die nehmen einem viel Arbeit

00:25:46.980 --> 00:25:48.800
weg, wenn man dann Produktivbetrieb hat. Die haben

00:25:48.800 --> 00:25:51.520
Sachen drin für Content-Delivery-Networks

00:25:51.520 --> 00:25:53.040
und die haben Sachen drin für Docker und die haben

00:25:53.040 --> 00:25:54.700
Sachen drin für Cached oder für

00:25:54.700 --> 00:25:57.240
sonst irgendwelche Sachen. Ich glaube, wenn man

00:25:57.240 --> 00:25:59.100
zum ersten Mal so ein Projekt macht, ist es

00:25:59.100 --> 00:25:59.620
einfacher,

00:26:00.520 --> 00:26:01.780
from scratch anzufangen.

00:26:02.820 --> 00:26:04.940
Weil man viele von diesen Sachen dann einfach nicht braucht.

00:26:05.720 --> 00:26:07.140
Das Blog, was man da

00:26:07.140 --> 00:26:09.100
als erstes Mal entwickelt,

00:26:09.200 --> 00:26:10.280
wird sicherlich nicht gleich

00:26:10.280 --> 00:26:12.400
100.000 Hits pro Minute haben.

00:26:12.560 --> 00:26:13.480
Woher willst du das denn wissen?

00:26:14.900 --> 00:26:17.140
Meine Blogs haben nie so viel gehabt.

00:26:18.140 --> 00:26:18.540
Vielleicht

00:26:18.540 --> 00:26:21.020
habt ihr mehr Erfolg als ich. Ich wünsche es euch.

00:26:22.360 --> 00:26:23.320
Aber es ist sicherlich

00:26:23.320 --> 00:26:24.960
nicht die erste Ausrichtung. Es wird sicherlich

00:26:24.960 --> 00:26:27.300
nicht das erste Problem

00:26:27.300 --> 00:26:28.980
sein, dafür zu sorgen, dass das die ganze Welt

00:26:28.980 --> 00:26:31.160
gleichzeitig lesen kann. Sondern das erste

00:26:31.160 --> 00:26:33.200
Problem wird sicherlich sein,

00:26:33.300 --> 00:26:34.680
dafür zu sorgen, dass es irgendjemand

00:26:34.680 --> 00:26:36.920
lesen kann. Und das überhaupt läuft.

00:26:37.040 --> 00:26:38.160
Ja, genau.

00:26:38.160 --> 00:26:40.220
dass man überhaupt einen Block hat.

00:26:40.320 --> 00:26:41.640
Und ich glaube, dann ist es einfacher,

00:26:41.880 --> 00:26:47.220
mit dem puren, mit dem Basis-Django umzugehen.

00:26:47.880 --> 00:26:49.920
Habt ihr ein Lieblingsmodul, ein Lieblingstemplate?

00:26:50.040 --> 00:26:52.620
Also wenn ihr das schon einsetzt im Produktivbetrieb?

00:26:54.320 --> 00:26:55.540
Das ist eine schwere Frage,

00:26:55.740 --> 00:26:59.360
weil da oft sehr viele Sachen zusammenkommen.

00:26:59.360 --> 00:27:03.360
Weil man oft sehr, sehr viele Bibliotheken reinlädt,

00:27:04.020 --> 00:27:06.260
die alle nur einen kleinen Teil machen.

00:27:06.580 --> 00:27:07.900
Das ist so, wie wenn ich dich frage, welches

00:27:07.900 --> 00:27:10.460
Lego-Teil ist denn dein Lieblings-Lego-Teil?

00:27:11.280 --> 00:27:11.640
Ritterburg.

00:27:12.180 --> 00:27:13.820
Ja, aber das ist ja kein einzelnes Teil.

00:27:13.960 --> 00:27:16.400
Das ist ja gleich was sehr Großes zusammengebaut.

00:27:16.400 --> 00:27:17.820
Da sind viele kleine Steine dabei, glaube ich.

00:27:18.080 --> 00:27:20.240
Genau, und die einzelnen Steine an sich sind alle nicht

00:27:20.240 --> 00:27:22.120
super interessant, aber wenn man sie dann zu was

00:27:22.120 --> 00:27:24.440
zusammengebaut hat, dann ist

00:27:24.440 --> 00:27:25.800
das, was man gebaut hat, super interessant.

00:27:27.700 --> 00:27:28.140
Okay, aber gut,

00:27:28.220 --> 00:27:30.460
du weißt ja dann schon, welche Steine du dann brauchst,

00:27:30.500 --> 00:27:32.120
damit du dann irgendwie sowas gießen kannst.

00:27:32.580 --> 00:27:32.980
Ja, klar.

00:27:33.960 --> 00:27:36.280
Das heißt, man hat sich schon so ein Workflow, an dem man sich dann gewohnt

00:27:36.280 --> 00:27:37.280
und er es dann auch irgendwie

00:27:37.280 --> 00:27:38.980
individuell spielt.

00:27:40.120 --> 00:27:41.460
Ja, aber auch da, also ich

00:27:41.460 --> 00:27:44.180
jedes Mal, wenn ich

00:27:44.180 --> 00:27:46.040
mit Leuten zusammenarbeite,

00:27:46.200 --> 00:27:47.900
dann bin ich wieder überrascht davon, wie

00:27:47.900 --> 00:27:50.260
unterschiedlich man die Sachen machen kann.

00:27:51.240 --> 00:27:52.200
Nicht schlechter

00:27:52.200 --> 00:27:53.540
oder besser bei irgendjemandem,

00:27:54.100 --> 00:27:56.060
aber einfach so unterschiedlich. Auf viele

00:27:56.060 --> 00:27:58.100
Sachen, die der Jochen macht, komme ich einfach gar nicht.

00:27:58.100 --> 00:27:59.560
Und das wird sicherlich umgekehrt sein.

00:28:00.000 --> 00:28:02.040
Genau das fände ich jetzt total interessant, also so

00:28:02.040 --> 00:28:04.000
Sachen von euch noch zu hören, wo

00:28:04.000 --> 00:28:05.580
sonst niemand drauf gekommen ist, wo er sagt, hey,

00:28:06.040 --> 00:28:07.500
Denk nochmal drüber nach, das wäre ein toller Tipp.

00:28:07.860 --> 00:28:09.440
Mach das doch mal diesen Weg oder

00:28:09.440 --> 00:28:11.980
Ja, also wenn ich da

00:28:11.980 --> 00:28:14.260
quasi eine

00:28:14.260 --> 00:28:16.240
App nennen sollte,

00:28:16.340 --> 00:28:17.100
wäre das wahrscheinlich

00:28:17.100 --> 00:28:19.280
Django ImageKit tatsächlich.

00:28:20.060 --> 00:28:20.920
Django ImageKit?

00:28:22.780 --> 00:28:23.460
Ich habe

00:28:23.460 --> 00:28:26.180
da mal so einen Blog in Django

00:28:26.180 --> 00:28:28.160
geschrieben und

00:28:28.160 --> 00:28:30.280
bin relativ bald auf das Problem

00:28:30.280 --> 00:28:32.360
gestoßen, dass man, wenn man jetzt so

00:28:32.360 --> 00:28:34.340
ja, wir haben 2018,

00:28:34.860 --> 00:28:36.820
will man schon so irgendwie responsivee Images haben

00:28:36.820 --> 00:28:38.840
und dass das halt auch auf dem Handy irgendwie einigermaßen

00:28:38.840 --> 00:28:40.820
aussieht. Aber man möchte jetzt auch nicht

00:28:40.820 --> 00:28:42.960
alle Bilder in riesig groß ausliefern.

00:28:44.480 --> 00:28:45.120
Wenn man

00:28:45.120 --> 00:28:46.900
ja eben auch

00:28:46.900 --> 00:28:48.520
gerade auf dem Handy und so

00:28:48.520 --> 00:28:50.880
und da muss man ja dann was

00:28:50.880 --> 00:28:52.620
tun. Also da gibt es Unterstützung in

00:28:52.620 --> 00:28:54.680
HTML5 durchaus,

00:28:55.900 --> 00:28:56.520
was

00:28:56.520 --> 00:28:58.420
solche Probleme angeht.

00:28:59.560 --> 00:29:00.760
Aber man muss das ja jetzt auch dann auch

00:29:00.760 --> 00:29:02.520
irgendwie backend-seitig hinbekommen.

00:29:02.520 --> 00:29:04.540
Also es muss halt die Bilder in unterschiedlichen Größen

00:29:04.540 --> 00:29:06.220
geben. Man muss halt irgendwie

00:29:06.220 --> 00:29:08.240
die entsprechenden

00:29:08.240 --> 00:29:10.340
Tags so rausschreiben,

00:29:10.500 --> 00:29:12.260
dass halt Source-Set-Attribut

00:29:12.260 --> 00:29:14.280
und vielleicht irgendwie

00:29:14.280 --> 00:29:16.180
noch andere Geschichten, Picture-Element

00:29:16.180 --> 00:29:18.300
so gesetzt sind, wie man das irgendwie haben will.

00:29:19.140 --> 00:29:20.560
Und ich war etwas überrascht,

00:29:20.640 --> 00:29:22.440
dass es da in Django quasi überhaupt gar nichts gibt.

00:29:23.060 --> 00:29:24.160
Also da gibt es zwar ein

00:29:24.160 --> 00:29:25.120
Image-Field, aber

00:29:25.120 --> 00:29:28.180
das war es auch schon. Das kennt dann halt irgendwie so

00:29:28.180 --> 00:29:29.280
noch

00:29:29.280 --> 00:29:31.960
Höhe und Breite gegenüber dem

00:29:31.960 --> 00:29:33.200
File-Field einfach,

00:29:34.120 --> 00:29:36.260
wenn man das verwendet, aber das hat

00:29:36.260 --> 00:29:37.880
eigentlich nicht viel Funktionalität dafür,

00:29:38.500 --> 00:29:40.480
sozusagen für diesen Use Case,

00:29:40.700 --> 00:29:42.180
den man oft hat, dass man das Bild wirklich

00:29:42.180 --> 00:29:43.340
auf einer Webseite anzeigen will

00:29:43.340 --> 00:29:45.580
und

00:29:45.580 --> 00:29:48.100
dann habe ich so ein bisschen geguckt und dann gibt es irgendwie so diverse

00:29:48.100 --> 00:29:50.180
Thumbnail-Libraries und so,

00:29:50.340 --> 00:29:52.080
die sind aber alle, die haben halt diesen

00:29:52.080 --> 00:29:54.060
Thumbnail-Use Case

00:29:54.060 --> 00:29:56.100
irgendwie, aber nicht, war nicht

00:29:56.100 --> 00:29:57.680
so richtig das, was ich irgendwie da gesucht hatte

00:29:57.680 --> 00:30:00.080
und dann habe ich dann irgendwie was selber implementiert und dann

00:30:00.080 --> 00:30:01.780
irgendwie ein paar

00:30:01.780 --> 00:30:04.200
Wochen

00:30:04.200 --> 00:30:05.860
später oder so lief mir Django ImageKit

00:30:05.860 --> 00:30:07.100
über den Weg, dass

00:30:07.100 --> 00:30:09.860
quasi, also ich weiß nicht,

00:30:09.900 --> 00:30:11.880
das waren schon bei mir so, keine Ahnung,

00:30:11.960 --> 00:30:13.880
ein paar hundert Zeilen Python oder so, die ich da geschrieben hatte

00:30:13.880 --> 00:30:15.960
und es war alles ein bisschen hässlich

00:30:15.960 --> 00:30:17.320
und ich wusste auch, dass das alles nicht schön war

00:30:17.320 --> 00:30:19.080
und das hat das halt komplett ersetzt.

00:30:19.580 --> 00:30:21.580
Ich musste es nur noch importieren und habe dann irgendwie

00:30:21.580 --> 00:30:22.120
da so meine

00:30:22.120 --> 00:30:25.320
Speck-Dinger an die

00:30:25.320 --> 00:30:27.660
Images reingeschrieben, sozusagen in welchen Größen

00:30:27.660 --> 00:30:29.620
ich das haben möchte und dann

00:30:29.620 --> 00:30:30.760
war es das. Voll gut.

00:30:31.780 --> 00:30:33.480
das hat dieses Problem irgendwie

00:30:33.480 --> 00:30:35.960
für mich mehr oder weniger erledigt

00:30:35.960 --> 00:30:38.060
und das fand ich

00:30:38.060 --> 00:30:40.040
sehr hilfreich und daher denke ich,

00:30:40.220 --> 00:30:41.760
dass das etwas ist,

00:30:42.020 --> 00:30:43.680
was andere auch interessieren könnte,

00:30:44.420 --> 00:30:46.080
weil den Fall, dass man Bilder

00:30:46.080 --> 00:30:48.220
ausliefern will auf einer Webseite, den hat man ja doch relativ oft.

00:30:49.200 --> 00:30:50.220
Klingt nach tollen Geheimtipps

00:30:50.220 --> 00:30:50.540
tatsächlich.

00:30:51.340 --> 00:30:53.860
Das ist jetzt nicht so ein Geheimtipp, das Ding ist relativ bekannt

00:30:53.860 --> 00:30:55.960
und das ist ein bisschen komisch, vielleicht, dass ich es nicht kannte, aber es ist

00:30:55.960 --> 00:30:57.900
oft so, dass man... Ja, es ist oft so, dass man als Anfänger

00:30:57.900 --> 00:30:59.940
irgendwo drüber stolpert und gar nicht weiß, wo man anfangen soll

00:30:59.940 --> 00:31:01.800
und das war so viel, da kriegt man auch gar nicht mit,

00:31:01.860 --> 00:31:02.920
was ist jetzt wichtig und was nicht.

00:31:03.420 --> 00:31:06.460
Aber ja, gerade für so responsivee Implementation,

00:31:06.560 --> 00:31:07.960
glaube ich, ist das ein super Tipp.

00:31:08.780 --> 00:31:10.980
Ich glaube, es ist nicht nur als Anfänger so,

00:31:11.120 --> 00:31:13.160
weil das ist total das gute Beispiel,

00:31:13.240 --> 00:31:14.320
was der Jochen jetzt bringt,

00:31:14.400 --> 00:31:16.280
weil ich habe Django ImageKit noch nie benutzt.

00:31:16.280 --> 00:31:18.140
Ah, ja.

00:31:18.920 --> 00:31:22.740
Das ist ein bisschen ein Problem in der Django-Welt.

00:31:22.820 --> 00:31:25.360
Die ist so groß, dass es für eigentlich alles was gibt,

00:31:25.600 --> 00:31:26.740
aber man muss es erst finden.

00:31:26.880 --> 00:31:28.940
Und man muss erst das finden, was zu einem passt.

00:31:29.620 --> 00:31:31.000
Ich habe ImageKit noch nie benutzt.

00:31:31.240 --> 00:31:34.360
Ich benutze Wagtail und da ist das immer integriert.

00:31:34.700 --> 00:31:36.460
Wie heißt das? Ich muss das kurz für die Show-Notes notieren.

00:31:36.660 --> 00:31:39.920
Der hat auch schon eine Bildverarbeitung.

00:31:40.740 --> 00:31:46.240
Wagtail ist eigentlich ein Bausatz für Content-Management-Systeme.

00:31:46.240 --> 00:31:50.480
Also es ist quasi ein Framework, was noch mal oberhalb von Django ist,

00:31:50.560 --> 00:31:52.720
was noch mehr Sachen mitbringt.

00:31:52.840 --> 00:31:55.300
Und der hat eben auch gleich dieses Bildproblem mitgelöst.

00:31:55.480 --> 00:31:58.060
Und deshalb benutze ich das immer gleich für meine Bilder auch.

00:31:59.620 --> 00:32:00.880
Ein Wagtail, okay.

00:32:02.500 --> 00:32:03.380
Kommt von einem

00:32:03.380 --> 00:32:04.980
Universum ins nächste. Ich glaube, da kann man

00:32:04.980 --> 00:32:07.380
Bücher, Wochen, Kurse mit

00:32:07.380 --> 00:32:09.300
füllen. Also das ist wirklich sehr interessant.

00:32:10.940 --> 00:32:11.260
Wobei

00:32:11.260 --> 00:32:13.040
mich jetzt auch interessieren würde,

00:32:13.240 --> 00:32:15.400
wie hat Wagtail das Problem

00:32:15.400 --> 00:32:16.120
dann gelöst?

00:32:17.300 --> 00:32:19.460
Gibt es irgendwie Default-Einstellungen, die man machen kann?

00:32:19.640 --> 00:32:21.340
Welche Bildgrößen gerechnet werden

00:32:21.340 --> 00:32:23.300
sollen und wie werden die dann tatsächlich

00:32:23.300 --> 00:32:25.380
gerechnet? Ich meine, sobald ein Bild hochgeladen

00:32:25.380 --> 00:32:27.000
wurde, werden dann die neuen Bilder erstellt oder

00:32:27.000 --> 00:32:28.620
erst beim Zugriff und dann gecached?

00:32:29.260 --> 00:32:30.620
Das kannst du alles einstellen.

00:32:30.840 --> 00:32:31.140
Ah, okay.

00:32:31.180 --> 00:32:32.760
Da gibt es ein Modul, das heißt Wagtail Images.

00:32:33.760 --> 00:32:36.120
Um einen mal kurz ein bisschen breiter auszuholen.

00:32:36.120 --> 00:32:38.780
Wagtail ist eine Sammlung von Modulen,

00:32:39.060 --> 00:32:42.180
die das Bauen von CMS-Systemen,

00:32:42.180 --> 00:32:45.040
also von Content-Management-Systemen, erleichtern sollen.

00:32:45.220 --> 00:32:46.860
Es gab da schon was, das heißt Django CMS.

00:32:47.020 --> 00:32:48.020
Das ist relativ alt.

00:32:49.020 --> 00:32:51.200
Hat auch mehr so diesen Flask-Ansatz.

00:32:51.360 --> 00:32:54.000
Hier sind 15 Module, baue sie zusammen, wie du willst.

00:32:54.580 --> 00:32:56.980
Wagtail hat mehr so diesen integrierten Ansatz.

00:32:57.900 --> 00:33:02.600
Du musst im Wesentlichen nur noch sogenannte Seitenmodelle liefern.

00:33:02.600 --> 00:33:06.300
Also du musst sagen, was auf einer Seite drauf sein soll für Felder.

00:33:06.880 --> 00:33:13.260
Und dann gibt es den Rectile-Admin, der diese Seiten eben inspiziert und mit reinnimmt

00:33:13.260 --> 00:33:19.060
und kriegst dann automatisch eben so eine Baumstruktur mit Revisionen und Freigabeprozess

00:33:19.060 --> 00:33:21.160
und eben Medienverwaltung auch mit dazu.

00:33:22.520 --> 00:33:24.460
Und die Medienverwaltung ist relativ flexibel.

00:33:24.560 --> 00:33:26.880
Es gibt so Default-Dinger, die eingestellt sind.

00:33:27.900 --> 00:33:33.620
Standardmäßig ist eingestellt, dass die Bilder beim Zugriff erstellt werden und dann gecached werden.

00:33:33.620 --> 00:33:44.620
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.

00:33:44.740 --> 00:33:51.200
Das heißt, es ist so ein bisschen die Mitte zwischen den beiden Extremen. Immer alles sofort anlegen und immer alles neu berechnen.

00:33:51.760 --> 00:33:54.240
Es wird berechnet, wenn es zum ersten Mal angefordert wird und dann wird es abgelegt.

00:33:55.280 --> 00:34:02.980
Eine Funktion, die mich hier ungeheuer beeindruckt hat, die sie einfach mal so eingebaut hatten, ist Content-Aware-Resize.

00:34:05.400 --> 00:34:11.260
Das ist so ein bisschen magisch und man muss das ein kleines bisschen freischalten.

00:34:12.140 --> 00:34:20.580
Aber wenn man das einmal eingestellt hat, dann heißt es, dass wenn OpenCV installiert ist, dann versucht er interessante Bildbereiche zu finden.

00:34:21.800 --> 00:34:24.260
Und wenn ich eine kleinere Version von dem Bild anfordere,

00:34:24.600 --> 00:34:25.940
dann wird nicht einfach der Rand

00:34:25.940 --> 00:34:28.000
weggeschnitten und das wird nicht einfach kleiner gemacht, sondern

00:34:28.000 --> 00:34:30.060
er zoomt dann quasi auf diesen Bereich rein.

00:34:30.560 --> 00:34:31.880
Das heißt, wenn ich ein Bild habe,

00:34:32.080 --> 00:34:34.200
wo eine Person drauf ist,

00:34:34.640 --> 00:34:36.280
dann wird auch das Gesicht der Person

00:34:36.280 --> 00:34:37.700
rein verkleinert.

00:34:38.220 --> 00:34:39.820
Und ich habe das

00:34:39.820 --> 00:34:41.740
irgendwann mal in so einer Vorstellung gesehen

00:34:41.740 --> 00:34:43.160
von Features in Marktail und das

00:34:43.160 --> 00:34:45.720
ist einfach so magisch. Die haben dieses Flag

00:34:45.720 --> 00:34:47.840
angemacht und dann plötzlich zeigt er mir eben nicht

00:34:47.840 --> 00:34:49.680
kleine, verkleinerte

00:34:49.680 --> 00:34:51.620
Versionen von irgendwas oder wo die Ränder

00:34:51.620 --> 00:34:53.640
dann abgeschnitten werden, sondern der zoomt

00:34:53.640 --> 00:34:55.160
tatsächlich auf die interessanten Bereiche ein.

00:34:56.100 --> 00:34:57.580
Und dass sowas in so eine

00:34:57.580 --> 00:34:59.120
Bibliothek einfach reinkommen kann,

00:34:59.400 --> 00:35:01.460
ist eine total geniale

00:35:01.460 --> 00:35:03.480
Sache auf der einen Seite, weil man eben ganz

00:35:03.480 --> 00:35:04.760
viele Funktionen da mitkriegt.

00:35:05.320 --> 00:35:06.680
Aber es ist auch so ein bisschen

00:35:06.680 --> 00:35:09.120
furchterregend, weil man eben

00:35:09.120 --> 00:35:10.920
ganz viele solche Funktionen drin hat,

00:35:11.500 --> 00:35:12.860
von denen man vielleicht gar nicht weiß, dass die

00:35:12.860 --> 00:35:14.520
da drin sind oder von denen man vielleicht gar nicht

00:35:14.520 --> 00:35:16.900
will, dass die da drin sind. Und es ist

00:35:16.900 --> 00:35:17.440
so ein bisschen

00:35:17.440 --> 00:35:20.900
schwierig, da oft abzuwägen,

00:35:21.620 --> 00:35:24.040
will ich sowas in mein Projekt reinholen

00:35:24.040 --> 00:35:24.440
oder nicht.

00:35:25.340 --> 00:35:27.900
Ja, ich weiß jetzt natürlich

00:35:27.900 --> 00:35:29.760
nicht, wie dieses Feature technisch

00:35:29.760 --> 00:35:31.100
umgesetzt ist, aber

00:35:31.100 --> 00:35:35.900
da gibt es

00:35:35.900 --> 00:35:36.220
halt

00:35:36.220 --> 00:35:39.320
quasi in HTML5

00:35:39.320 --> 00:35:41.700
das Picture Element und das kann halt

00:35:41.700 --> 00:35:43.740
im Grunde, die nennen das da Art Direction,

00:35:43.940 --> 00:35:45.540
sozusagen, dass man angeben kann, welcher Bildbereich beim

00:35:45.540 --> 00:35:47.480
Verkleinern sichtbar bleiben soll und so.

00:35:47.480 --> 00:35:48.160
Und wenn

00:35:48.160 --> 00:35:49.680
Wagtail

00:35:49.680 --> 00:35:52.200
das so benutzt, dann wäre das

00:35:52.200 --> 00:35:54.320
natürlich sehr cool. Es könnte natürlich

00:35:54.320 --> 00:35:56.300
auch einfach das Bild irgendwie umrechnen oder so

00:35:56.300 --> 00:35:57.980
und das wäre halt so,

00:35:58.120 --> 00:36:00.160
das kommt halt darauf an, wie das implementiert ist

00:36:00.160 --> 00:36:02.240
und eigentlich würde man sich ja dann vielleicht auch ein Frontend

00:36:02.240 --> 00:36:04.160
wünschen, mit dem man festlegen kann,

00:36:04.280 --> 00:36:06.080
okay, also dieser Bereich in dem Bild ist jetzt

00:36:06.080 --> 00:36:08.180
etwas, was nicht

00:36:08.180 --> 00:36:09.460
rausverkleinert werden soll.

00:36:10.480 --> 00:36:12.180
Aber da habe ich eben auch nichts gefunden. Ich habe mir natürlich

00:36:12.180 --> 00:36:13.600
also, als ich da irgendwie mein

00:36:13.600 --> 00:36:16.340
persönliches Blog

00:36:16.340 --> 00:36:17.940
irgendwie angefangen habe zu schreiben, habe ich mir

00:36:17.940 --> 00:36:19.740
angeguckt, wie sieht das eigentlich aus, wenn ich jetzt

00:36:19.740 --> 00:36:21.740
einen WordPress-Blog aufmache,

00:36:22.080 --> 00:36:24.020
was passiert denn eigentlich da mit den

00:36:24.020 --> 00:36:25.920
Bildern und dann sieht man da so, ja gut, also die machen

00:36:25.920 --> 00:36:27.840
das im Grunde, da werden dann halt auch ein paar Größen vorgerechnet

00:36:27.840 --> 00:36:29.760
und die werden dann halt mit ausgeliefert als Source-Set

00:36:29.760 --> 00:36:32.160
und man hat so ein bisschen,

00:36:32.280 --> 00:36:33.620
kann man an dem Bild was machen, man kann irgendwas

00:36:33.620 --> 00:36:36.020
beschneiden oder man kann halt irgendwie

00:36:39.900 --> 00:36:40.260
die

00:36:40.260 --> 00:36:40.620
quasi

00:36:40.620 --> 00:36:43.000
so ein paar Editiergeschichten

00:36:43.000 --> 00:36:44.340
machen, aber letztendlich

00:36:44.340 --> 00:36:46.680
kann man zum Beispiel, was dieses Picture-Element

00:36:46.680 --> 00:36:48.380
kann, kann man auch in WordPress alles nicht setzen.

00:36:49.280 --> 00:36:50.660
Und es gibt

00:36:50.660 --> 00:36:52.320
eigentlich kaum Frontends für

00:36:52.320 --> 00:36:54.880
all die Möglichkeiten, die man jetzt mit dem Picture-Element

00:36:54.880 --> 00:36:56.240
hätte. Und

00:36:56.240 --> 00:36:58.820
ja, das ist halt, genau,

00:36:58.920 --> 00:37:00.380
wenn das automatisch passiert,

00:37:00.840 --> 00:37:02.480
dann ist halt immer die Gefahr, dass dann Dinge

00:37:02.480 --> 00:37:05.640
hinterher zu sehen

00:37:05.640 --> 00:37:06.760
sind, die gar nicht so,

00:37:06.920 --> 00:37:08.600
wo niemand, wenn er das

00:37:08.600 --> 00:37:09.460
manuell getan hätte,

00:37:10.080 --> 00:37:12.460
das ausgewählt hätte. Aber

00:37:12.460 --> 00:37:15.140
ja, also die Möglichkeiten sind natürlich schon groß.

00:37:19.060 --> 00:37:20.820
Du hattest eben gesagt, dass das

00:37:20.820 --> 00:37:22.820
Probleme machen könnte, zu viele Module

00:37:22.820 --> 00:37:24.820
in einen dann gut zu packen, die man

00:37:24.820 --> 00:37:26.760
gar nicht möchte. Gibt es dann

00:37:26.760 --> 00:37:28.740
Sicherheitsbedenken, die du dann da bekommst?

00:37:29.840 --> 00:37:30.900
Sicherheitsbedenken habe ich da eigentlich

00:37:30.900 --> 00:37:32.500
relativ wenige. Dadurch, dass

00:37:32.500 --> 00:37:34.900
da einige Sicherheitsstandards

00:37:35.560 --> 00:37:36.940
in Django selbst umgesetzt

00:37:36.940 --> 00:37:38.320
sind, sind so diese

00:37:38.320 --> 00:37:40.840
ganzen Unsicherheiten, die man so

00:37:40.840 --> 00:37:42.620
kennt, die sind da alle direkt

00:37:42.620 --> 00:37:44.660
ausgeschlossen. Also es gibt diese

00:37:44.660 --> 00:37:46.820
ganz bekannte Sicherheitslücke SQL Injection,

00:37:48.680 --> 00:37:50.920
dass man eben die Datenbank dazu bringt,

00:37:51.020 --> 00:37:52.800
Code auszuführen, der eigentlich nicht ausgeführt

00:37:52.800 --> 00:37:54.560
werden sollte. Und das ist in Django

00:37:54.560 --> 00:37:56.860
direkt nur

00:37:56.860 --> 00:37:58.720
mit sehr viel Aufwand möglich, muss man so

00:37:58.720 --> 00:38:00.900
zu sagen. Man kann es hinkriegen,

00:38:01.000 --> 00:38:02.560
dass man so eine Lücke hat, aber man muss

00:38:02.560 --> 00:38:04.120
dann schon die

00:38:04.120 --> 00:38:06.700
verborgenen Features benutzen, die es

00:38:06.700 --> 00:38:08.320
einem eben ermöglichen, ein hohes SQL

00:38:08.320 --> 00:38:10.820
da auszuführen. Ein normaler

00:38:10.820 --> 00:38:12.820
Entwickler wird niemals dieses Problem

00:38:12.820 --> 00:38:14.780
haben, da eine SQL-Injection

00:38:14.780 --> 00:38:16.700
in Django zu haben. Es ist mehr

00:38:16.700 --> 00:38:18.780
so eine, es ist weniger eine Frage

00:38:18.780 --> 00:38:20.800
der Sicherheit, es ist eher eine Sache

00:38:20.800 --> 00:38:22.240
der Handhabbarkeit.

00:38:22.960 --> 00:38:24.860
Komme ich als Entwickler dann noch damit klar,

00:38:24.960 --> 00:38:26.440
was ich mir jetzt alles reingeholt habe?

00:38:26.840 --> 00:38:28.280
Oder habe ich vielleicht Sachen reingeholt,

00:38:29.100 --> 00:38:30.640
die die gleiche Funktion

00:38:30.640 --> 00:38:32.300
erfüllen? Habe ich vielleicht Wacktail und

00:38:32.300 --> 00:38:33.980
Django ImageKit reingeholt?

00:38:34.660 --> 00:38:35.620
Und dann

00:38:35.620 --> 00:38:38.040
stehe ich da und habe

00:38:38.040 --> 00:38:40.500
zu viele Optionen in der Hand, als dass

00:38:40.500 --> 00:38:41.860
ich dann weiterentwickeln könnte

00:38:41.860 --> 00:38:44.300
oder als ich dann sinnvoll

00:38:44.300 --> 00:38:45.280
weiterentwickeln könnte,

00:38:46.040 --> 00:38:48.060
weil es eben für

00:38:48.060 --> 00:38:50.120
jede Sache, die ich machen kann,

00:38:50.320 --> 00:38:51.680
eventuell mehrere Optionen gibt.

00:38:54.720 --> 00:38:56.740
Es ist

00:38:56.740 --> 00:38:58.200
sicherlich von außen nicht sichtbar.

00:38:58.380 --> 00:39:00.180
Wenn die Anwendung dann fertig ist oder wenn die

00:39:00.180 --> 00:39:02.340
irgendwie mal benutzt wird, wird

00:39:02.340 --> 00:39:03.920
der Benutzer das sicherlich nicht sehen können,

00:39:04.200 --> 00:39:06.140
dass wir da diese Probleme

00:39:06.140 --> 00:39:08.200
uns reingeholt haben, indem wir zu viele Module

00:39:08.200 --> 00:39:10.140
reingeladen haben. Es ist dann

00:39:10.140 --> 00:39:12.060
eher was, was die Entwickler betrifft.

00:39:12.220 --> 00:39:14.000
Wie können wir jetzt noch weiterentwickeln, wenn wir

00:39:14.000 --> 00:39:16.040
drei oder vier verschiedene Sachen haben, die genau das

00:39:16.040 --> 00:39:18.040
Gleiche machen? Ja, und wenn man dann Abhängigkeiten

00:39:18.040 --> 00:39:20.160
hat, man ist beispielsweise in einem Teil

00:39:20.160 --> 00:39:21.720
der Applikation abhängig von einer

00:39:21.720 --> 00:39:23.700
bestimmten Version irgendeiner,

00:39:23.880 --> 00:39:25.700
von irgendeinem

00:39:25.700 --> 00:39:27.500
Django-Sort-Party-App oder so,

00:39:27.960 --> 00:39:30.060
und im anderen Teil ist man von was anderem abhängig, dann hat man plötzlich

00:39:30.060 --> 00:39:31.200
Schwierigkeiten zu updaten. Das

00:39:31.200 --> 00:39:33.620
macht halt die Entwicklungsgeschwindigkeit

00:39:33.620 --> 00:39:36.260
langsam, wenn man sich quasi so

00:39:36.260 --> 00:39:37.920
unnötigerweise viele

00:39:37.920 --> 00:39:40.020
Abhängigkeiten nach außen reinholt, während

00:39:40.020 --> 00:39:41.980
Und wenn man das halt sinnvoll beschränkt,

00:39:42.080 --> 00:39:46.040
dann kommt man eigentlich immer ganz gut halt auch mit Updates klar.

00:39:47.600 --> 00:39:50.840
Wenn ich jetzt so eine Auswahl habe, ich habe jetzt mehrere Optionen,

00:39:51.000 --> 00:39:54.660
wen frage ich denn da, welche von diesen Optionen für mich jetzt die bessere wäre?

00:39:54.800 --> 00:39:56.860
Tja, das ist eine sehr gute Frage.

00:39:57.060 --> 00:40:01.260
Und wenn ich die beantworten könnte, dann wäre auch mein Leben viel einfacher.

00:40:03.200 --> 00:40:05.180
Vieles davon läuft eben über Gespräche.

00:40:05.380 --> 00:40:09.880
Man spricht mit den Leuten in seinen Python-User-Groups

00:40:09.880 --> 00:40:12.420
oder in seinen Django-User-Groups oder auf den Konferenzen

00:40:12.420 --> 00:40:15.820
oder mit den Kollegen, mit denen man vielleicht zusammenarbeitet.

00:40:15.900 --> 00:40:17.960
Und jeder wird da sicherlich Dinge wissen,

00:40:19.500 --> 00:40:21.620
von denen man selbst noch nie gehört hat,

00:40:21.700 --> 00:40:23.380
egal wie lange man in dem Business drin ist.

00:40:23.820 --> 00:40:25.560
Jochen und ich sind ja jetzt beide schon länger unterwegs

00:40:25.560 --> 00:40:26.600
und wir können uns sicherlich,

00:40:27.060 --> 00:40:28.540
wenn wir uns da einen Abend lang unterhalten,

00:40:28.640 --> 00:40:30.620
finden wir beide zehn Sachen, die der andere noch nicht musste

00:40:30.620 --> 00:40:32.100
oder die der andere noch nie benutzt hat.

00:40:34.560 --> 00:40:37.140
Es gibt eine Webseite, die heißt Django Packages.

00:40:38.220 --> 00:41:04.700
Die versuchen so ein bisschen, das zu sortieren und die versuchen so ein bisschen, da diese Themenbereiche aufzuarbeiten und das vielleicht auf so ein bisschen eine rationale Ebene zu ziehen, muss man sozusagen, wo sie einfach sagen, okay, was gibt es denn zum Bereich, keine Ahnung, Bildbearbeitung und wie stabil ist das und wie viele Leute benutzen das und für welche Django-Versionen ist das geeignet und welche Features hat das, dass man einfach mal so eine Übersicht haben kann.

00:41:04.700 --> 00:41:10.140
Kann ich mir so ein kleines Scorecard bauen? Also was ist jetzt für mein Nutzen vielleicht? Das empfohlenste Paket?

00:41:11.500 --> 00:41:25.880
Beziehungsweise man sieht dann einfach erst mal, was es gibt überhaupt. Das ist oft einfach eine sehr große Hilfe, wenn man sieht, okay, es gibt hier 15 verschiedene Bibliotheken, aber 10 davon sind schon seit Jahren nicht mehr geupdatet worden. Dann kann ich die gleich aus der Betrachtung rausziehen.

00:41:26.440 --> 00:41:28.780
Vielleicht auch, wenn ich mir die vorher schon angeguckt hatte

00:41:28.780 --> 00:41:30.000
und die sehr gut aussahen.

00:41:30.360 --> 00:41:32.180
Wenn es keine Updates mehr gibt,

00:41:32.300 --> 00:41:34.560
dann ist das oft ein Anzeichen dafür,

00:41:34.660 --> 00:41:36.440
dass die Entwickler es sich anders überlegt haben

00:41:36.440 --> 00:41:39.280
oder dass sie vielleicht in ein anderes Projekt reingemerged sind.

00:41:39.320 --> 00:41:41.260
Kann nicht sein, dass auf einmal so ein Ding fertig ist.

00:41:42.160 --> 00:41:45.120
Das kann auch sein, aber es ist unwahrscheinlich.

00:41:47.240 --> 00:41:48.920
Wann wird Software je fertig?

00:41:49.460 --> 00:41:51.560
Und jede neue Version von Django

00:41:51.560 --> 00:41:53.460
bietet natürlich auch Möglichkeiten,

00:41:53.460 --> 00:41:55.720
Dinge wieder neu oder anders oder einfacher zu machen

00:41:55.720 --> 00:41:56.640
und dann eigentlich

00:41:56.640 --> 00:41:59.400
wahrscheinlich nicht immer, aber ab und zu muss man halt

00:41:59.400 --> 00:42:01.340
doch mal was anfassen und wenn man

00:42:01.340 --> 00:42:02.780
nix mehr anfassen muss, dann

00:42:02.780 --> 00:42:05.420
ja, eben ist es eher ein Zeichen dafür, dass

00:42:05.420 --> 00:42:07.200
es nicht mehr richtig maintained wird.

00:42:08.180 --> 00:42:09.700
Und ja, Django Packages

00:42:09.700 --> 00:42:11.200
wird übrigens von einem der beiden

00:42:11.200 --> 00:42:11.980
Autoren

00:42:11.980 --> 00:42:15.580
Duskus of Django betrieben,

00:42:15.840 --> 00:42:17.520
dem,

00:42:17.520 --> 00:42:18.100
der auch

00:42:18.100 --> 00:42:20.960
Crispy Forms geschrieben hat,

00:42:21.240 --> 00:42:23.160
was erklärt, warum es die Präferenz ist.

00:42:24.140 --> 00:42:25.540
Ja, also die machen da

00:42:25.540 --> 00:42:26.320
ganz viel und

00:42:26.320 --> 00:42:29.540
ja, Django Packages

00:42:29.540 --> 00:42:30.900
ist tatsächlich eine große Hilfe, aber

00:42:30.900 --> 00:42:33.520
so oft ist es auch schwer zu erkennen, also ich

00:42:33.520 --> 00:42:35.460
finde das oft nicht so einfach,

00:42:35.740 --> 00:42:37.300
wenn man jetzt irgendwie ein Problem hat, das man

00:42:37.300 --> 00:42:39.360
gelöst haben möchte und man jetzt

00:42:39.360 --> 00:42:41.380
hat man da so eine Auswahl von

00:42:41.380 --> 00:42:42.620
zehn unterschiedlichen Paketen,

00:42:43.360 --> 00:42:45.260
es ist wirklich nicht einfach zu sagen, ja,

00:42:45.400 --> 00:42:46.000
welches davon

00:42:46.000 --> 00:42:48.940
man nehmen sollte.

00:42:49.200 --> 00:42:51.620
Ohne jetzt alle zu kennen schon. Genau, das kann man ja auch gar nicht.

00:42:51.620 --> 00:42:53.160
Man kann die gar nicht alle kennen und

00:42:53.160 --> 00:42:55.760
Und selbst wenn man dann mal zwei, drei reingeguckt hat,

00:42:55.980 --> 00:42:58.880
dann ist das nicht so einfach zu sagen.

00:42:59.300 --> 00:43:00.660
Manchmal muss man halt dann Glück haben

00:43:00.660 --> 00:43:03.020
oder irgendwie sich später nochmal umentscheiden.

00:43:03.360 --> 00:43:06.160
Aber das ist tatsächlich ein großes Problem.

00:43:06.720 --> 00:43:10.700
Also wie wählt man die Software aus,

00:43:10.760 --> 00:43:12.140
von der man abhängig sein möchte?

00:43:13.780 --> 00:43:16.240
Ja, und jeder baut so mit der Zeit

00:43:16.240 --> 00:43:19.160
seine eigenen Vorlieben und seine eigenen Präferenzen auf.

00:43:19.500 --> 00:43:21.800
Und die sind schwer austauschbar.

00:43:22.000 --> 00:43:23.580
Es ist super interessant, sich

00:43:23.580 --> 00:43:25.700
darüber zu unterhalten, aber sie sind sehr schwer

00:43:25.700 --> 00:43:26.340
austauschbar.

00:43:29.260 --> 00:43:31.500
Gibt es was wie gute und schlechte Module

00:43:31.500 --> 00:43:33.920
oder ist das eher nur eine Präferenzenfrage?

00:43:35.900 --> 00:43:37.860
Es gibt sicherlich gute und schlechte Module,

00:43:38.160 --> 00:43:39.220
aber nicht

00:43:39.220 --> 00:43:41.480
auf so einer absoluten Ebene.

00:43:41.620 --> 00:43:43.580
Also ich könnte jetzt nicht auf irgendeinem Modul zeigen und sagen,

00:43:43.700 --> 00:43:45.580
das ist schlecht. Wenn du das benutzt, dann bist du ein schlechter

00:43:45.580 --> 00:43:45.840
Mensch.

00:43:47.960 --> 00:43:48.760
Es ist eher...

00:43:48.760 --> 00:43:51.540
Das Cookie-Law-Modul

00:43:51.540 --> 00:43:53.480
vielleicht, wenn man

00:43:53.480 --> 00:43:55.240
keine Cookies einsetzen müsste.

00:43:55.800 --> 00:43:57.440
Wenn man keine Cookies hat. Aber es gibt

00:43:57.440 --> 00:43:59.480
ganz viele Leute, die sowas anschalten und gar keine

00:43:59.480 --> 00:44:01.520
Cookies haben oder so. Ja, aber das ist ja in Django

00:44:01.520 --> 00:44:03.260
immer so. In Django hast du immer den Session-Cookie.

00:44:03.720 --> 00:44:04.900
Also müsstest du eigentlich immer.

00:44:06.620 --> 00:44:07.600
Auch wenn der Sessions gar nicht

00:44:07.600 --> 00:44:09.540
benutzt, hast du immer einen Session-Cookie. Also müsstest

00:44:09.540 --> 00:44:11.460
du eigentlich immer das Modul direkt

00:44:11.460 --> 00:44:13.500
einschalten. Muss man die Cookie-Warnung

00:44:13.500 --> 00:44:15.300
tatsächlich auch bei Session? Ich dachte nur, wenn man tatsächlich

00:44:15.300 --> 00:44:17.340
ein persistentes Cookie setzt

00:44:17.340 --> 00:44:18.320
im Browser.

00:44:20.300 --> 00:44:21.120
Soweit ich weiß,

00:44:21.540 --> 00:44:23.260
Muss man es immer? Immer, wenn du

00:44:23.260 --> 00:44:25.360
Informationen über den Benutzer speicherst.

00:44:25.460 --> 00:44:27.100
Und das tust du ja in dem Moment. Ah, okay.

00:44:27.200 --> 00:44:28.400
Ja, dann muss man es immer. Mist.

00:44:31.240 --> 00:44:32.580
Okay, das klingt super. Also nach

00:44:32.580 --> 00:44:35.220
den Themen, die wir schon immer

00:44:35.220 --> 00:44:35.940
machen wollten.

00:44:37.280 --> 00:44:39.240
Ich glaube, Artikel 6 oder sowas ist da spannend. Da kann man

00:44:39.240 --> 00:44:41.240
einfach sagen, hey, das muss ich machen,

00:44:41.320 --> 00:44:43.160
deswegen darf ich das auch. Und dann müsst ihr einfach mit

00:44:43.160 --> 00:44:45.140
zufrieden sein. Ich muss euch da gar nicht Bescheid geben und

00:44:45.140 --> 00:44:47.120
gut ist. Ja, klar.

00:44:47.120 --> 00:44:49.000
Es gibt ja auch verschiedene Arten, wie man

00:44:49.000 --> 00:44:51.060
damit umgehen kann. Ich habe neulich

00:44:51.060 --> 00:44:52.860
eine Cookie-Warnung gesehen, da stand einfach nur drin,

00:44:52.940 --> 00:44:54.840
wir müssen sie informieren, dass wir Cookies setzen,

00:44:54.920 --> 00:44:56.160
das haben wir hier mitgetan.

00:44:57.140 --> 00:44:59.280
Da kann man sich dann vor Gericht streiten, ob das ausreichend war.

00:45:00.500 --> 00:45:01.100
Ja, aber

00:45:01.100 --> 00:45:02.160
ja.

00:45:03.900 --> 00:45:05.160
Mir fällt das

00:45:05.160 --> 00:45:06.660
schwer, das zu verstehen manchmal,

00:45:06.860 --> 00:45:08.760
was da bestimmte Regulierungen irgendwie

00:45:08.760 --> 00:45:09.960
eigentlich nützen sollen und

00:45:09.960 --> 00:45:13.100
Leuten, die da noch weniger in zum Beispiel EU-Verordnungen

00:45:13.100 --> 00:45:14.960
dran sitzen in den USA, denen fällt das

00:45:14.960 --> 00:45:16.940
möglicherweise noch schwerer und dann kriegt man

00:45:16.940 --> 00:45:18.840
teilweise so fast schon

00:45:18.840 --> 00:45:20.560
passiv-aggressiv anmutende

00:45:20.560 --> 00:45:22.800
so Geschichten so, willst du die Seite

00:45:22.800 --> 00:45:24.760
wirklich weiter benutzen, dann drück jetzt hier

00:45:24.760 --> 00:45:25.860
Meldung.

00:45:27.440 --> 00:45:27.800
Ja,

00:45:28.840 --> 00:45:30.620
naja, gut, wahrscheinlich muss man einfach damit leben,

00:45:30.740 --> 00:45:33.040
dass es halt manchmal ein bisschen nervig ist, wenn Dinge geregelt werden.

00:45:33.040 --> 00:45:35.060
Und dann haben die Leute, die das nicht verstehen,

00:45:35.200 --> 00:45:37.060
irgendwann ausgedient und dann kommen Leute, die es ein bisschen

00:45:37.060 --> 00:45:39.040
besser verstehen, die sagen dann, mach den

00:45:39.040 --> 00:45:41.000
Schrott weg oder so, hoffentlich.

00:45:41.400 --> 00:45:43.020
Man weiß es nicht, kann natürlich immer alles schlimmer

00:45:43.020 --> 00:45:45.080
werden, aber ich glaube mir mal an das Gute

00:45:45.080 --> 00:45:45.680
im Menschen, ja.

00:45:46.560 --> 00:45:48.980
Ja, ist ja immer Politik irgendwie zwei Schritte vor,

00:45:49.200 --> 00:45:51.280
drei zurück, nein, warte mal, drei früher, zwei zurück

00:45:51.280 --> 00:45:51.700
hoffentlich.

00:45:53.100 --> 00:45:54.880
Oder im Kreis, kann man auch mal sagen.

00:45:56.380 --> 00:45:56.820
Ja, ja.

00:45:59.280 --> 00:46:00.820
Was habt ihr denn an Neuigkeiten für Django?

00:46:01.000 --> 00:46:03.420
Ist euch da was eingefallen, was in letzter Zeit da zukam,

00:46:03.500 --> 00:46:05.100
wo ihr sagtet, ey, wow, guckt euch das

00:46:05.100 --> 00:46:05.760
unbedingt nochmal an?

00:46:06.900 --> 00:46:09.080
Es gibt da eigentlich immer neue Sachen zu sehen.

00:46:10.340 --> 00:46:10.980
Django hat

00:46:10.980 --> 00:46:12.920
vor kurzem seinen, ja, vor kurzem,

00:46:13.220 --> 00:46:15.060
vor langer Zeit, hat schon

00:46:15.060 --> 00:46:17.500
seit langer Zeit einen sehr schnellen Release-Zyklus.

00:46:18.460 --> 00:46:18.660
Und

00:46:18.660 --> 00:46:20.720
Entschuldigung, was heißt schnell?

00:46:21.440 --> 00:46:22.620
Schnell heißt, dass die

00:46:22.620 --> 00:46:24.740
sagen, alle neun Monate

00:46:24.740 --> 00:46:26.900
kommt eine neue Version von Django raus.

00:46:27.640 --> 00:46:28.880
Immer ein nächstes Baby.

00:46:29.420 --> 00:46:30.740
Genau. Und

00:46:30.740 --> 00:46:32.760
jede dritte Version von Django ist

00:46:32.760 --> 00:46:34.540
eine sogenannte LTS-Version, eine

00:46:34.540 --> 00:46:37.080
Long-Time-Support oder Long-Term-Support.

00:46:37.700 --> 00:46:38.900
Das heißt, dass die mindestens für

00:46:38.900 --> 00:46:40.300
Jochen Kurier mich drei Jahre

00:46:40.300 --> 00:46:42.140
Sicherheitsupdates bekommen.

00:46:44.480 --> 00:46:45.040
Und

00:46:45.040 --> 00:46:46.300
das heißt, dass es ab jetzt

00:46:46.300 --> 00:46:48.700
regelmäßig neue Major-Versionen gibt,

00:46:49.040 --> 00:46:50.420
weil die eben dieses Namensschema

00:46:50.420 --> 00:46:52.380
umgestellt haben. Wir sind jetzt gerade bei

00:46:52.380 --> 00:46:54.520
Django 2.1. Die nächste

00:46:54.520 --> 00:46:56.460
Version, 2.2, wird eben so eine

00:46:56.460 --> 00:46:58.720
LTS-Version sein, die dann für längere

00:46:58.720 --> 00:46:59.060
Zeit

00:46:59.060 --> 00:47:02.800
gültig ist oder unterstützt

00:47:02.800 --> 00:47:04.560
wird, muss man so sagen. Und die

00:47:04.560 --> 00:47:06.080
Version danach ist Django 3.0.

00:47:07.260 --> 00:47:08.500
Und üblicherweise erwartet

00:47:08.500 --> 00:47:10.540
man ja bei Versionssprüngen

00:47:10.540 --> 00:47:12.460
immer viele Neuigkeiten und

00:47:12.460 --> 00:47:14.040
ich glaube, dass das auch hier so sein wird. Also

00:47:14.040 --> 00:47:20.060
Also der Sprung von 1.11, was die gerade aktive LTS-Version ist, auf 2.0,

00:47:20.840 --> 00:47:24.040
da waren schon einige Sachen drin, die sich deutlich geändert haben.

00:47:24.700 --> 00:47:29.480
Was für mich am offensichtlichsten war, ist der Sprung von URL zu Path,

00:47:30.640 --> 00:47:36.400
wo sich die Definition der verfügbaren URLs in Django verändert hat.

00:47:37.380 --> 00:47:41.260
Früher in dem alten URL-Schema hat man einfach reguläre Ausdrücke angegeben.

00:47:42.500 --> 00:47:46.300
Ein regulärer Ausdruck ist so eine Beschreibung für einen Text, für ein Textmuster.

00:47:46.980 --> 00:47:51.340
Und wenn dieses Textmuster gepasst hat, dann ist eben diese passende Funktion dazu aufgerufen worden.

00:47:51.420 --> 00:47:55.800
Man musste sich dann aber immer noch selbst darum kümmern, dass, wenn da jetzt zum Beispiel eine Jahreszahl drin war,

00:47:56.340 --> 00:48:01.620
dass die zu einer Zahl wurde, weil die natürlich aus diesem Text erstmal nur als Text rausgekommen ist.

00:48:02.680 --> 00:48:07.260
Und dieses Problem haben sie in 2.0 geändert. Das heißt jetzt nicht mehr URL, sondern Path.

00:48:07.440 --> 00:48:11.160
Und man gibt eben nicht mehr so ein Textmuster an, sondern man gibt so ein Parametermuster an.

00:48:11.620 --> 00:48:25.860
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.

00:48:25.860 --> 00:48:46.080
Und das nimmt einem viel Arbeit weg, weil man eben nicht mehr dafür sorgen muss, dass die Parameter passen. Ist aber auch erstmal ein Umdenken. Wenn man so lange mit den regulären Ausdrücken gearbeitet hat, dass man sich daran gewöhnt hat, dann verliert man oft den Blick dafür, was überhaupt möglich ist und ob das überhaupt gut ist.

00:48:46.380 --> 00:49:13.360
Ja, wobei ich finde, also reguläre Ausdrücke sind natürlich toll und man kann sie für ganz viele Sachen verwenden und wenn man sich da mal so zwei Stunden oder einen halben Tag reingefuchst hat, dann sieht das für einen auch alles ganz natürlich aus irgendwie, aber wenn man das halt, wenn man jetzt Django entwickelt, dann hat man mit diesen URL-Patterns eigentlich immer nur so ab und zu mal zu tun, wenn man halt irgendwie ein neues Modul reintut oder neue Views definiert und das ist eigentlich gar nicht so super häufig, also das kommt schon vor,

00:49:13.360 --> 00:49:42.800
Aber bei mir ist es jedenfalls so, dass ich eigentlich fast immer, wenn ich sowas dann, wenn ich das URL-Pattern geändert habe, dass ich dann irgendwie in alte Projekte geguckt habe oder nochmal Doku lesen musste, so wie macht man das denn jetzt eigentlich nochmal, weil ich mir das nie, wie geht das mit der Gruppe und dann wird das zu einem Variablen-Namen, wo schreibt man den nochmal hin, kommt das P jetzt davor, dahinter oder muss ich jetzt da ein Fragezeichen, also das war immer, ich musste es immer nachgucken und dann, das ist natürlich irgendwie so ein bisschen ein schlechtes Zeichen, weil das ist dann irgendwie nicht intuitiv.

00:49:42.940 --> 00:49:46.300
Und das jetzt mit diesen Pass-Geschichten tatsächlich deutlich besser.

00:49:46.600 --> 00:49:50.680
Also da steht dann immer nur so Doppelpunkt, also Int oder String.

00:49:50.900 --> 00:49:52.120
Ich weiß nicht genau, es gibt auch gar nicht so viele.

00:49:52.220 --> 00:49:55.100
Es gibt noch Slug und ich glaube Pass oder so.

00:49:55.220 --> 00:49:56.400
Man kann sich selber welche schreiben.

00:49:56.760 --> 00:49:57.460
Man kann sich selber welche schreiben.

00:49:57.500 --> 00:49:58.220
Oh, das ist ja super.

00:49:58.320 --> 00:49:59.840
Das wusste ich jetzt zum Beispiel auch nicht.

00:50:00.220 --> 00:50:00.800
Das ist ja voll gut.

00:50:01.480 --> 00:50:02.820
Ja, man kann sich selber welche schreiben.

00:50:03.180 --> 00:50:04.320
Es gibt verschiedene Möglichkeiten.

00:50:04.460 --> 00:50:07.140
Du kannst entweder direkt reguläre Ausdrücke machen.

00:50:07.280 --> 00:50:09.780
Also wenn du halt irgendwas ganz Bestimmtes merken musst.

00:50:09.860 --> 00:50:11.480
Oder du kannst welche, die es gibt, zusammentun.

00:50:11.960 --> 00:50:29.580
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.

00:50:30.780 --> 00:50:32.480
Oh, das ist ja großartig. Das müssen wir mal angucken, wie das geht.

00:50:34.600 --> 00:50:36.660
Ja, siehst du, und das ist so ein bisschen das Schöne,

00:50:36.760 --> 00:50:38.300
das ist so ein bisschen das, was immer passiert,

00:50:38.480 --> 00:50:40.980
wenn Django-Experten zusammensitzen.

00:50:41.700 --> 00:50:42.900
Dann sagt einer irgendwas und der andere

00:50:42.900 --> 00:50:44.620
sagt, oh, das ist ja cool, das wusste ich noch gar nicht,

00:50:44.680 --> 00:50:46.000
das muss ich unbedingt mal anschauen.

00:50:47.300 --> 00:50:48.560
Und das geht mir da eigentlich

00:50:48.560 --> 00:50:49.440
regelmäßig so.

00:50:49.440 --> 00:50:49.780
Ja.

00:50:51.520 --> 00:50:52.000
Ja.

00:50:55.500 --> 00:50:57.160
Ja, ich weiß nicht genau, ob

00:50:57.160 --> 00:50:59.160
für 3.0 jetzt schon so ein Thema,

00:50:59.260 --> 00:51:01.340
ich habe irgendwie so

00:51:01.340 --> 00:51:03.320
am Rande mitbekommen, dass auch

00:51:03.320 --> 00:51:05.400
für 2.0 im Grunde schon angedacht war,

00:51:06.220 --> 00:51:07.540
ob man jetzt nicht doch irgendwie

00:51:07.540 --> 00:51:09.660
so ein bisschen mehr

00:51:09.660 --> 00:51:12.280
wie

00:51:12.280 --> 00:51:15.600
Kommunikation mit dem

00:51:15.600 --> 00:51:17.420
Client mit in Django reinnehmen kann, aber

00:51:17.420 --> 00:51:19.100
das geht jetzt auch schon seit einiger Zeit

00:51:19.100 --> 00:51:21.400
irgendwie in den

00:51:21.400 --> 00:51:23.340
neueren HTTP-Versionen, dass man quasi auch

00:51:23.340 --> 00:51:25.340
über WebSockets wieder mit dem Client vom

00:51:25.340 --> 00:51:27.340
Server aus zurücksprechen kann

00:51:27.340 --> 00:51:29.000
und es gibt diverse

00:51:29.000 --> 00:51:31.320
Fälle, wo das ja auch total sinnvoll ist, dass man das

00:51:31.320 --> 00:51:33.300
tut. Aber das

00:51:33.300 --> 00:51:34.760
passt halt nicht so richtig auf dieses

00:51:34.760 --> 00:51:37.360
ja, auf diese Schnittstelle

00:51:37.360 --> 00:51:37.840
zwischen

00:51:37.840 --> 00:51:41.080
Web-Server und Applikationen.

00:51:41.600 --> 00:51:43.200
WSGI, WSGI-Schnittstelle gibt

00:51:43.200 --> 00:51:45.140
das halt eigentlich nicht her. Und

00:51:45.140 --> 00:51:47.420
da muss halt noch eine ganze Menge Infrastruktur

00:51:47.420 --> 00:51:49.280
geändert werden. Und es gab

00:51:49.280 --> 00:51:50.960
da dieses Django-Channels-Projekt und

00:51:50.960 --> 00:51:53.640
es gibt es immer noch.

00:51:53.640 --> 00:51:55.440
Ja. Und da war ja

00:51:55.440 --> 00:51:56.680
irgendwie schon

00:51:56.680 --> 00:51:59.620
mal irgendwie quasi sozusagen angedacht,

00:51:59.760 --> 00:52:01.820
in Django 2 mit reinzunehmen, aber

00:52:01.820 --> 00:52:03.720
das ist dann halt irgendwie nicht passiert, wahrscheinlich weil zu viel

00:52:03.720 --> 00:52:05.780
angepasst werden musste. Und vielleicht kommt das ja

00:52:05.780 --> 00:52:07.040
dann in 3, ich habe keine Ahnung.

00:52:08.760 --> 00:52:09.800
Das ist eine ganz spannende

00:52:09.800 --> 00:52:11.880
Sache, das muss man sich auch mal

00:52:11.880 --> 00:52:13.800
genauer angucken, weil da viele Dinge möglich werden,

00:52:13.900 --> 00:52:14.840
die vorher nicht möglich waren.

00:52:16.000 --> 00:52:17.780
Ist aber eben technisch ganz anders,

00:52:17.900 --> 00:52:19.900
weil wir ja nicht mehr in dieses klassische Web-Schema

00:52:19.900 --> 00:52:21.180
reinfallen, wo der Benutzer

00:52:21.180 --> 00:52:23.840
eben eine Webseite aufruft und dann kriegt er die zurück,

00:52:23.940 --> 00:52:25.620
sondern weil es jetzt eben auf einmal

00:52:25.620 --> 00:52:27.640
eine Verbindung gibt, wo der

00:52:27.640 --> 00:52:29.520
Server potenziell selbst sagen kann,

00:52:29.600 --> 00:52:30.840
hier ist was passiert, mach mal was.

00:52:31.720 --> 00:52:33.000
Und das ist eine ganz spannende Sache.

00:52:35.000 --> 00:52:35.900
Ja, auch technisch

00:52:35.900 --> 00:52:37.440
super interessant. Da haben sie sich

00:52:37.440 --> 00:52:39.620
einen neuen Standard, mehr oder weniger

00:52:39.620 --> 00:52:40.540
ausgedacht, ASGI.

00:52:42.260 --> 00:52:43.380
Was dann halt auch neue

00:52:43.380 --> 00:52:45.600
Server-Backends erfordert. Daphne heißt der Server.

00:52:45.880 --> 00:52:47.280
Genau, genau. Man kann nicht einfach irgendwie

00:52:47.280 --> 00:52:49.540
Unicorn nehmen oder den normalen

00:52:49.540 --> 00:52:51.000
Entwicklungs-Server von Django, sondern, ja.

00:52:51.180 --> 00:52:53.360
Und da ändert sich dann einiges. Man kann schon den

00:52:53.360 --> 00:52:54.980
normalen Entwicklungs-Server nehmen, weil der

00:52:54.980 --> 00:52:57.120
das direkt mit integriert hat. Also wenn du

00:52:57.120 --> 00:52:58.620
Channels installierst,

00:52:58.620 --> 00:52:59.500
Ach, wenn man es installiert, dann kommt das Ding.

00:52:59.500 --> 00:53:01.480
Dann kriegst du eine andere Variante von Run-Server

00:53:01.480 --> 00:53:04.420
und der das automatisch, der automatisch WebSockets bringt,

00:53:04.600 --> 00:53:07.320
damit du eben in der Entwicklung den Unterschied nicht merkst.

00:53:07.800 --> 00:53:07.920
Ja.

00:53:09.400 --> 00:53:11.900
Aber das Arbeiten damit ist deutlich anders,

00:53:12.020 --> 00:53:13.480
weil du eben diese Kanäle hast

00:53:13.480 --> 00:53:15.800
und nicht mehr so dieses Request-Response.

00:53:16.140 --> 00:53:16.320
Ja.

00:53:16.320 --> 00:53:17.120
Schema ist.

00:53:18.080 --> 00:53:20.000
Das muss man jetzt mal kurz erklären. Also ich habe jetzt

00:53:20.000 --> 00:53:21.800
ganz kurz fast nur Barm verstanden.

00:53:23.000 --> 00:53:24.460
Request-Response-Schema, ja.

00:53:24.680 --> 00:53:26.120
Kanäle, hä?

00:53:27.560 --> 00:53:28.120
Was ist das?

00:53:28.760 --> 00:53:29.200
Die

00:53:29.200 --> 00:53:32.280
früher, als das Web

00:53:32.280 --> 00:53:33.240
noch jung war,

00:53:34.040 --> 00:53:35.940
war die Idee,

00:53:36.460 --> 00:53:38.080
dass eine Webseite eigentlich nie

00:53:38.080 --> 00:53:39.280
einen Zustand haben sollte.

00:53:40.100 --> 00:53:42.240
Das heißt, du fragst eine URL an

00:53:42.240 --> 00:53:44.080
und kriegst das Ergebnis, oder kriegst das,

00:53:44.080 --> 00:53:46.000
was da auf dieser URL steht, zurück.

00:53:46.320 --> 00:53:48.900
Und mit Error 402 Payment Required, ja.

00:53:49.140 --> 00:53:56.760
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.

00:53:56.940 --> 00:54:01.700
Cookies sind im Wesentlichen der Zustand, den du mitlieferst, wenn du eine Webseite anguckst.

00:54:01.920 --> 00:54:15.520
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.

00:54:15.520 --> 00:54:17.900
und zeig dann entsprechend die richtige Variante an.

00:54:20.400 --> 00:54:25.200
Ist sehr schön, weil man da die Seiten eben so dynamisch generieren kann,

00:54:25.280 --> 00:54:28.320
dass sie für den Benutzer zugeschnitten sind, der jetzt gerade da ist.

00:54:28.820 --> 00:54:30.280
Weil wir ja wissen, wer sich eingeloggt hat.

00:54:30.400 --> 00:54:32.400
Oder weil wir vielleicht wissen, was der gestern gekauft hat.

00:54:32.500 --> 00:54:36.820
Oder weil wir vielleicht wissen, keine Ahnung, was der für einen Computer hat oder irgendwie sowas.

00:54:39.820 --> 00:54:41.820
Das Schema ist aber immer noch Request-Response.

00:54:41.820 --> 00:55:02.280
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.

00:55:02.280 --> 00:55:04.120
Und ihr wartet immer, bis der Browser wieder fragt.

00:55:04.280 --> 00:55:06.100
Genau, die Verbindung ist dann erst mal weg

00:55:06.100 --> 00:55:07.620
und der Browser muss dann fragen.

00:55:10.040 --> 00:55:13.540
Jetzt haben Browser in der Zwischenzeit JavaScript bekommen

00:55:13.540 --> 00:55:15.360
und haben eben die Möglichkeit erhalten,

00:55:16.080 --> 00:55:17.180
regelmäßig zu fragen.

00:55:17.680 --> 00:55:19.080
Das ist zum Beispiel das, was Twitter macht

00:55:19.080 --> 00:55:21.220
oder das, was Facebook macht.

00:55:22.860 --> 00:55:24.740
Wenn da ein Newsfeed sich aktualisiert,

00:55:24.840 --> 00:55:26.340
dann fragen die halt alle 30 Sekunden,

00:55:26.420 --> 00:55:27.340
gibt es was Neues für mich?

00:55:28.220 --> 00:55:30.240
Und dann sagt der Server in den allermeisten Fällen nein.

00:55:30.740 --> 00:55:31.700
Und wenn es doch was Neues gibt,

00:55:31.700 --> 00:55:37.640
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.

00:55:39.260 --> 00:55:47.760
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,

00:55:47.860 --> 00:55:54.740
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.

00:55:54.740 --> 00:56:23.020
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.

00:56:23.020 --> 00:56:27.480
Dafür brauchst du aber eine Verbindung zwischen dem Server und dem Client, die die ganze Zeit da sein muss.

00:56:28.300 --> 00:56:30.460
Ist das nicht dann das Netz viel mehr ausgelastet?

00:56:31.080 --> 00:56:37.320
Nee, es ist eigentlich weniger ausgelastet, weil du eben nicht die ganze Zeit leere Anfragen schicken musst.

00:56:37.900 --> 00:56:43.540
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.

00:56:44.120 --> 00:56:45.860
Also insofern hast du eine Ressource belegt.

00:56:46.720 --> 00:57:00.600
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.

00:57:02.620 --> 00:57:23.380
Und das gibt dir eigentlich zwei Vorteile. Zum einen sparst du dir die Bandbreite, dass du die ganze Zeit fragen musst, auch wenn nichts passiert ist. Und zum anderen hast du natürlich eine viel schnellere Antwortzeit, weil es nicht mehr davon abhängt, wie oft der Client fragt, dass er Updates bekommt, sondern wenn ein Update passiert, kann der Server sofort sagen, jetzt ist was passiert.

00:57:24.280 --> 00:57:47.780
Das heißt, wenn ich mir meine Chat-Anwendung schreibe und der Client fragt halt nur alle 30 Sekunden, gibt es was Neues, dann sehe ich auch nur alle 30 Sekunden, ob jemand was geschrieben hat. Wenn der Server sagen kann, hier ist was Neues, dann kann ich das sofort ausliefern. Das heißt, es wird sehr viel responsiver, sehr viel schneller in der Verarbeitung.

00:57:48.520 --> 00:57:50.000
Und Latenz direkt verfügbar.

00:57:50.000 --> 00:58:11.840
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.

00:58:12.000 --> 00:58:14.960
Also immer ein Request und das ist halt jetzt ein Riesenvorteil, ja?

00:58:14.960 --> 00:58:17.600
Ja, ich glaube

00:58:17.600 --> 00:58:18.200
es gab da auch

00:58:18.200 --> 00:58:21.400
noch Dinge, bevor man das halt

00:58:21.400 --> 00:58:23.460
mit JavaScript gemacht hat, es gab solche

00:58:23.460 --> 00:58:25.580
furchtbaren Dinge wie Longpolling, wo dann der Server

00:58:25.580 --> 00:58:27.460
immer gesagt hat, ja

00:58:27.460 --> 00:58:29.800
nee, client, warte mal, ist noch nicht ganz fertig

00:58:29.800 --> 00:58:31.600
warte mal, Moment

00:58:31.600 --> 00:58:33.540
und dann

00:58:33.540 --> 00:58:35.780
ab und zu mal doch wieder so ein Content-Bröckchen

00:58:35.780 --> 00:58:37.300
an den Client weitergeschickt hat

00:58:37.300 --> 00:58:39.920
und

00:58:39.920 --> 00:58:40.860
also es gab da

00:58:40.860 --> 00:58:43.080
diverse furchtbare Geschichten, die gemacht wurden

00:58:43.080 --> 00:58:45.700
und im Grunde jetzt WebSockets

00:58:45.700 --> 00:58:47.480
und eine stehende

00:58:47.480 --> 00:58:49.620
Verbindung löst all das eigentlich relativ

00:58:49.620 --> 00:58:51.020
sauber und

00:58:51.020 --> 00:58:52.980
ja, damit kann man wirklich tolle Sachen

00:58:52.980 --> 00:58:55.500
machen und es

00:58:55.500 --> 00:58:57.560
gab ja auch, es gibt

00:58:57.560 --> 00:58:59.360
auch schon komplette Frameworks

00:58:59.360 --> 00:59:00.460
und komplette

00:59:00.460 --> 00:59:03.780
Technologie-Stacks,

00:59:03.780 --> 00:59:05.820
die halt darauf basieren, dass man sowas machen kann.

00:59:05.960 --> 00:59:07.440
Also wenn man jetzt zum Beispiel in die JavaScript-Welt guckt,

00:59:07.580 --> 00:59:09.140
Meteor oder so, die sind halt,

00:59:09.740 --> 00:59:11.920
das ist halt vom Backend bis zum Frontend

00:59:11.920 --> 00:59:12.940
darauf ausgerichtet, dass

00:59:12.940 --> 00:59:15.900
man dem Client irgendwie Dinge schicken kann

00:59:15.900 --> 00:59:17.940
und damit kann man halt Sachen

00:59:17.940 --> 00:59:19.080
bauen, die

00:59:19.080 --> 00:59:22.120
ja, wenn man das sowas zum ersten Mal

00:59:22.120 --> 00:59:23.940
sieht, relativ verblüffend aussehen, weil sie

00:59:23.940 --> 00:59:26.080
anders sind als das, was man so von

00:59:26.080 --> 00:59:27.920
Web-Anwendungen gewohnt ist.

00:59:28.380 --> 00:59:29.960
Jetzt hast du gerade wieder einen Begriff gesagt, ein Meteor.

00:59:30.380 --> 00:59:31.840
Ja, das ist halt so, dieser

00:59:31.840 --> 00:59:34.040
Stack ist heute auch nicht mehr so relevant, das war mal eine Zeit

00:59:34.040 --> 00:59:36.020
lang irgendwie halbwegs

00:59:36.020 --> 00:59:38.120
hip und das ist halt irgendwie

00:59:38.120 --> 00:59:40.040
als Datenbank verwendet,

00:59:40.100 --> 00:59:43.340
dass halt irgendwie dieses da, Dings da, MongoDB,

00:59:44.120 --> 00:59:49.440
das kann halt quasi diese Verbindungen auch,

00:59:49.540 --> 00:59:53.580
oder wenn was irgendwie passiert, direkt wieder an den Server,

00:59:53.760 --> 00:59:57.320
dass dann irgendwie ein eigenes Node.js-Basics-Dings

00:59:57.320 --> 00:59:59.660
irgendwie weiterreichen und das Ding reicht es halt komplett

00:59:59.660 --> 01:00:02.040
durch an den Client und du hast halt sozusagen

01:00:02.040 --> 01:00:05.840
Model-View-Kontrolle aber mit dem Client direkt drin

01:00:05.840 --> 01:00:08.180
und auf dem Client oder auf dem Server kann der gleiche Code laufen

01:00:08.180 --> 01:00:10.020
und so und das ist alles sehr schick und das bedeutet, also

01:00:10.020 --> 01:00:12.100
damit sieht dann halt so eine Anwendung quasi

01:00:12.100 --> 01:00:13.720
genauso aus wie eine

01:00:13.720 --> 01:00:16.240
ja, wie so eine

01:00:16.240 --> 01:00:18.120
Desktop-Applikation im Grunde, was

01:00:18.120 --> 01:00:20.000
die Reaktivität angeht.

01:00:20.100 --> 01:00:22.040
Man drückt irgendeinen Knopf und sofort

01:00:22.040 --> 01:00:24.140
bei jemand anders in einem anderen Browser

01:00:24.140 --> 01:00:26.000
irgendwie sieht man, dass dieser

01:00:26.000 --> 01:00:27.560
Knopf gedrückt wurde und

01:00:27.560 --> 01:00:29.600
es passt, ja, also

01:00:29.600 --> 01:00:32.580
Statusänderungen

01:00:32.580 --> 01:00:34.100
sind halt sozusagen instantan für alle, die

01:00:34.100 --> 01:00:36.040
es betrifft, sichtbar und das ist

01:00:36.040 --> 01:00:38.060
halt etwas, was man normalerweise jetzt so nicht hat. Das hat man

01:00:38.060 --> 01:00:39.960
auch bei Django nicht oder das kann man dann schon machen,

01:00:40.120 --> 01:00:41.840
aber das ist dann halt immer irgendwie so eine

01:00:41.840 --> 01:00:44.000
Sonder-Locker und das ist halt nicht irgendwie

01:00:44.000 --> 01:00:45.720
in dem Framework mit integriert, sondern

01:00:45.720 --> 01:00:48.100
ja, halt immer so ein bisschen

01:00:48.100 --> 01:00:49.180
dran vorbei.

01:00:51.080 --> 01:00:52.080
Aber das wäre natürlich schön,

01:00:52.160 --> 01:00:53.880
wenn man das halt direkt mit drin hätte

01:00:53.880 --> 01:00:55.680
und das kann natürlich gut sein, dass das jetzt demnächst dann

01:00:55.680 --> 01:00:58.080
in einer größeren Major-Version

01:00:58.080 --> 01:01:00.060
kommt. Ja, ansonsten kann man

01:01:00.060 --> 01:01:01.800
sich Journals ja auch so reinholen. Ja, kann man auch machen.

01:01:02.440 --> 01:01:04.220
Also implementiert

01:01:04.220 --> 01:01:06.120
Django dann Module, die es vorher schon gab

01:01:06.120 --> 01:01:08.300
oder schreibst komplett eigene Dinge selber?

01:01:08.580 --> 01:01:10.380
Sind da vorher Requests für vorhanden,

01:01:10.800 --> 01:01:12.140
dass tatsächlich die Entwickler gucken,

01:01:12.300 --> 01:01:13.720
hey, was ist denn so an Bedarf da?

01:01:13.840 --> 01:01:15.840
Oder kommen die mit eigenen kreativen Ideen?

01:01:17.320 --> 01:01:22.820
Ja, es gibt, Django ist ein sehr großes Open-Source-Projekt.

01:01:23.900 --> 01:01:25.760
Wie viele Entwickler gibt es da ungefähr?

01:01:27.040 --> 01:01:28.700
Es ist schwer zu sagen, aber es gibt eine Stiftung.

01:01:28.840 --> 01:01:30.220
Es gibt die Django Software Foundation.

01:01:30.440 --> 01:01:31.700
Also sie sind irgendwann so groß geworden,

01:01:31.820 --> 01:01:33.040
dass sie eine Stiftung gegründet haben.

01:01:34.160 --> 01:01:35.940
Also Leute, die Vollzeit auch ein bisschen dafür bezahlt werden,

01:01:36.000 --> 01:01:37.040
dass sie Moodle weiterentwickeln.

01:01:37.220 --> 01:01:41.080
Genau, da gibt es so ein paar Programme, wie das möglich ist.

01:01:41.080 --> 01:01:44.740
Und die haben auf jeden Fall genügend finanzielle Ressourcen,

01:01:44.900 --> 01:01:48.280
um sich am Leben zu halten und um eben dieses Projekt am Leben zu halten.

01:01:48.820 --> 01:01:53.700
Heißt eben aber auch, dass da inzwischen relativ viel Community-Management drin ist,

01:01:53.920 --> 01:01:56.640
weil eben die Community so groß ist, weil es so viele Leute gibt,

01:01:56.760 --> 01:02:02.380
die Django einsetzen, dass es notwendig wird, da Prozesse zu haben.

01:02:03.740 --> 01:02:23.660
Die meiste Weiterentwicklung kommt, glaube ich, tatsächlich aus der Entwickler-Community, wo einer, der es haben möchte, einfach sagt, ich mache das jetzt mal und dann zeige ich es allen Leuten und wir schauen, ob das funktioniert oder nicht. Also es ist sehr viel da, es ist nicht so zentralisiert, wie man das in anderen Projekten vielleicht kennt, sondern es passiert sehr viel einfach aus der Community heraus.

01:02:24.560 --> 01:02:37.340
Es gibt auch jedes Jahr Konferenzen zu dem Thema. Es gibt die DjangoCon, die jedes Jahr in den USA stattfindet. Es gibt die DjangoCon Europe, die jedes Jahr in einer Stadt Europas durchführt wird.

01:02:37.340 --> 01:02:38.900
Wo ist sie nächstes Jahr und wo war sie dieses Jahr?

01:02:39.040 --> 01:02:41.840
Dieses Jahr war sie in Heidelberg im Mai.

01:02:42.400 --> 01:02:43.620
Ja, fast in die Ecke.

01:02:44.280 --> 01:02:47.120
Nächstes Jahr ist sie in Kopenhagen, wenn ich das richtig weiß.

01:02:47.780 --> 01:03:05.960
Und das wird auch immer von der Community organisiert. Also die Software, die DSF, die Django Software Foundation sagt ganz spezifisch, wir wollen, dass das Amateure machen, weil wir eben die Community, die Benutzer mit einbeziehen wollen in den Prozess der Weiterentwicklung.

01:03:07.460 --> 01:03:14.160
Und die Django Con Europe, vor ein paar Jahren war die in Südfrankreich und da hatten sie so eine Insel. Die hatten einfach eine komplette Insel gemietet.

01:03:15.460 --> 01:03:15.940
Hübsch.

01:03:15.940 --> 01:03:18.060
Das ist jedes Mal anders und das ist auch so ein bisschen

01:03:18.060 --> 01:03:19.500
der Reiz da dran. Warst du da?

01:03:20.120 --> 01:03:21.860
In Heidelberg war ich da zum ersten Mal.

01:03:22.480 --> 01:03:23.680
War sehr angenehm.

01:03:23.980 --> 01:03:26.320
War eben vor dem studentischen

01:03:26.320 --> 01:03:28.460
Hintergrund Heidelbergs auch ganz nett.

01:03:29.220 --> 01:03:30.040
Nächstes Jahr in

01:03:30.040 --> 01:03:31.800
Kopenhagen werde ich wohl nicht dazu kommen können,

01:03:32.060 --> 01:03:33.840
aber ich war schon mal in Kopenhagen.

01:03:33.920 --> 01:03:34.820
Das ist auch sehr schön.

01:03:36.380 --> 01:03:37.920
Und ich kann es eigentlich jedem nur empfehlen

01:03:37.920 --> 01:03:39.800
und jede DjangoCon Europe ist so ein bisschen anders,

01:03:39.900 --> 01:03:42.000
weil die eben von

01:03:42.000 --> 01:03:43.880
Leuten aus dieser Gegend

01:03:43.880 --> 01:03:46.860
organisiert wird, die vorher vielleicht noch nie so eine

01:03:46.860 --> 01:03:48.860
Konferenz organisiert hat. Also auf der nächsten Insel schaue ich

01:03:48.860 --> 01:03:49.720
wahrscheinlich auch mal vorbei.

01:03:51.300 --> 01:03:52.520
Es lohnt sich auf jeden Fall.

01:03:52.660 --> 01:03:54.640
Es ist super, da die Leute

01:03:54.640 --> 01:03:56.660
kennenzulernen. Und man hat auch

01:03:56.660 --> 01:03:58.420
Kontakt da mit den

01:03:58.420 --> 01:04:00.960
Core-Entwicklern, also mit den Leuten, die sich tagtäglich

01:04:00.960 --> 01:04:02.580
damit beschäftigen. Und das ist natürlich super.

01:04:04.000 --> 01:04:04.740
Und gerade jetzt bei dem

01:04:04.740 --> 01:04:06.780
Channels-Projekt, ich habe da auch

01:04:06.780 --> 01:04:08.700
ein paar Leute kennengelernt und habe dann auch direkt

01:04:08.700 --> 01:04:09.480
was mit denen zusammen

01:04:09.480 --> 01:04:12.420
angefangen zu bearbeiten.

01:04:12.820 --> 01:04:14.300
Oh, das klingt ja auf jeden Fall

01:04:14.300 --> 01:04:15.040
schon mal echt gut.

01:04:16.140 --> 01:04:19.840
Ja, ansonsten, ich weiß gar nicht,

01:04:20.980 --> 01:04:24.040
inwiefern das da mit

01:04:24.040 --> 01:04:26.000
reingreift, was halt auch interessant

01:04:26.000 --> 01:04:28.160
wäre. Es gibt ja in Python

01:04:28.160 --> 01:04:28.900
jetzt so eine

01:04:28.900 --> 01:04:32.220
ziemlich schicke Syntax

01:04:32.220 --> 01:04:32.980
für AsyncIO.

01:04:34.260 --> 01:04:36.060
Und was eigentlich

01:04:36.060 --> 01:04:37.880
ja schon immer toll gewesen wäre, aber nie so richtig

01:04:37.880 --> 01:04:39.620
geklappt hat, war, dass man diese

01:04:39.620 --> 01:04:41.740
Asynchronizität, die man nach draußen hat,

01:04:42.100 --> 01:04:43.620
mit den Requests,

01:04:43.900 --> 01:04:46.280
Web-Requests, die halt reinkommen, dass man die halt weiterreicht.

01:04:47.480 --> 01:04:47.840
Sondern

01:04:47.840 --> 01:04:49.480
zum Beispiel an

01:04:49.480 --> 01:04:52.080
Datenbanken oder irgendwelche APIs, die man fragt.

01:04:52.720 --> 01:04:53.900
So momentan ist es halt so,

01:04:54.000 --> 01:04:55.920
wenn man jetzt, weiß ich nicht, um eine Seite zu

01:04:55.920 --> 01:04:57.700
bauen, zehn Statements irgendwie

01:04:57.700 --> 01:04:59.800
an die Datenbank schicken muss, dann werden

01:04:59.800 --> 01:05:01.820
die halt da seriell hingeschickt und

01:05:01.820 --> 01:05:03.820
abgearbeitet und dann, wenn die

01:05:03.820 --> 01:05:05.700
fertig sind, dann zeigt man die Seite an, was

01:05:05.700 --> 01:05:07.640
ein bisschen doof ist, weil das halt

01:05:07.640 --> 01:05:09.580
jedes Mal die Latenz, also die halt durchaus ein paar

01:05:09.580 --> 01:05:11.800
oder auch vielleicht mal ein paar zehn Millisekunden

01:05:11.800 --> 01:05:13.780
sein kann pro Statement. Das addiert sich

01:05:13.780 --> 01:05:15.280
halt alles auf und dann am Schluss

01:05:15.280 --> 01:05:16.700
quasi

01:05:16.700 --> 01:05:19.240
hat man halt, ist die

01:05:19.240 --> 01:05:21.740
Zeit, die man braucht, um halt quasi

01:05:21.740 --> 01:05:23.820
Content auszuliefern. Das ist ja eine wichtige Zeit, weil

01:05:23.820 --> 01:05:25.820
erst ab da ja alles losgeht, auch wenn

01:05:25.820 --> 01:05:27.720
man hinterher Bilder

01:05:27.720 --> 01:05:29.120
parallel holen kann oder so.

01:05:29.760 --> 01:05:32.000
Das geht aber nur, wenn man weiß, wie die Build-URLs

01:05:32.000 --> 01:05:33.640
sind. Das heißt, solange nicht irgendwie

01:05:33.640 --> 01:05:36.060
Content vom Applikationsserver

01:05:36.060 --> 01:05:37.780
gekommen ist, passiert nichts weiter.

01:05:37.920 --> 01:05:38.920
Holst du noch mal einen Kaffee?

01:05:40.560 --> 01:05:41.340
Genau, und

01:05:41.340 --> 01:05:44.160
dümmerweise sind halt in diesem

01:05:44.160 --> 01:05:46.220
kritischen Zeitbereich halt

01:05:46.220 --> 01:05:48.260
solche Dinge wie halt, dass

01:05:48.260 --> 01:05:50.580
alle SQL-Statements

01:05:50.580 --> 01:05:52.180
und Serielle geholt werden müssen und das ist natürlich

01:05:52.180 --> 01:05:54.100
eigentlich ziemlich blöd und schöner wäre es ja, wenn man

01:05:54.100 --> 01:05:56.160
irgendwie alle gleichzeitig abfeuern würde und

01:05:56.160 --> 01:05:58.200
dann würde man die halt irgendwie so einsammeln

01:05:58.200 --> 01:06:00.200
und dann wäre sozusagen das

01:06:00.200 --> 01:06:01.920
längste Statement

01:06:01.920 --> 01:06:04.280
irgendwie vielleicht das, was darüber entscheidet, wie lange es dauert,

01:06:04.380 --> 01:06:06.120
aber man müsste nicht

01:06:06.120 --> 01:06:06.960
irgendwie

01:06:06.960 --> 01:06:10.260
quasi auf jedes Einzelne warten.

01:06:10.600 --> 01:06:12.300
das könnte die Zeit deutlich verringern

01:06:12.300 --> 01:06:13.280
und

01:06:13.280 --> 01:06:16.520
ja, im Grunde könnte man da auch

01:06:16.520 --> 01:06:18.740
eine ähnliche Schnittstelle verwenden, wie für

01:06:18.740 --> 01:06:20.880
Asynchro

01:06:20.880 --> 01:06:24.700
Asynchro-Geschichten nach vorne raus

01:06:24.700 --> 01:06:25.860
und

01:06:25.860 --> 01:06:28.500
da weiß ich gar nicht, ob es, und bisher war das

01:06:28.500 --> 01:06:30.440
halt immer problematisch, weil man kann es halt irgendwie mit

01:06:30.440 --> 01:06:32.440
den vielen unterschiedlichen Geschichten, die es in Python

01:06:32.440 --> 01:06:34.480
da gibt, machen, man kann Threads nehmen, man kann halt

01:06:34.480 --> 01:06:36.560
irgendwie Twisted nehmen

01:06:36.560 --> 01:06:37.720
oder so, aber

01:06:37.720 --> 01:06:39.280
Frido habe ich letztens kennengelernt.

01:06:39.700 --> 01:06:41.200
Das ist voll super, aber

01:06:41.200 --> 01:06:43.620
ja,

01:06:44.740 --> 01:06:46.060
im Grunde, jetzt hätte man halt die Möglichkeit

01:06:46.060 --> 01:06:48.120
zu sagen, okay, da wir jetzt dann eine Syntax

01:06:48.120 --> 01:06:49.340
für haben, dann machen wir das einfach so.

01:06:49.800 --> 01:06:51.900
Und das wäre natürlich auch eine interessante Geschichte. Ich weiß auch,

01:06:51.980 --> 01:06:53.880
dass Flask irgendwie,

01:06:54.140 --> 01:06:55.860
dass da zumindest ein Projekt gibt, das versucht Flask

01:06:55.860 --> 01:06:57.300
umzubauen, dass das halt alles

01:06:57.300 --> 01:06:59.900
I.O. kompatibel

01:06:59.900 --> 01:07:01.680
sozusagen ist. Und bei Django

01:07:01.680 --> 01:07:03.740
weiß ich jetzt gar nicht wieder, wie weit das ist oder ob es da überhaupt

01:07:03.740 --> 01:07:04.320
Bestrebungen gibt.

01:07:05.760 --> 01:07:07.080
Aber sowas wäre natürlich auch sehr nett.

01:07:07.340 --> 01:07:07.740
Keine Ahnung.

01:07:09.080 --> 01:07:10.440
Ja, wüsste ich jetzt auch nicht, Freyhand.

01:07:10.520 --> 01:07:11.780
Aber es hört sich so an, als ob du mal

01:07:11.780 --> 01:07:14.440
ein Enhancement-Proposal einreichen solltest.

01:07:15.780 --> 01:07:17.540
Und vielleicht ein Fellowship beantragen,

01:07:17.640 --> 01:07:18.360
das du ja auch machst.

01:07:22.420 --> 01:07:22.780
Ja.

01:07:24.780 --> 01:07:25.560
Tja, tja, tja.

01:07:25.720 --> 01:07:27.480
Ist wahrscheinlich auch nicht so einfach, muss man sagen.

01:07:28.820 --> 01:07:30.280
Ja gut, aber wenn es einfach wäre,

01:07:30.280 --> 01:07:31.320
dann wäre es auch langweilig.

01:07:31.340 --> 01:07:32.780
Das hat ja auch schon wahrscheinlich jemand gemacht, ja.

01:07:34.540 --> 01:07:35.000
Ja, ja.

01:07:35.320 --> 01:07:38.060
Wir machen es nicht, weil es einfach ist, sondern wir machen es, weil es schwer ist.

01:07:38.060 --> 01:07:48.680
Ja, was gibt es noch so an interessanten Django-Themen?

01:07:48.800 --> 01:07:50.360
Ach ja, vielleicht sollte man das auch noch erwähnen.

01:07:51.700 --> 01:07:57.120
Genau, die Art, wie dieser Podcast publiziert wird.

01:07:57.120 --> 01:07:59.600
Da habe ich mir natürlich auch gedacht,

01:07:59.720 --> 01:08:05.200
okay, wenn ich da jetzt schon irgendwie Django entwickle,

01:08:05.300 --> 01:08:08.360
dann wäre es ja eigentlich schon ziemlich beschämend,

01:08:08.360 --> 01:08:11.620
irgendwie WordPress zu nehmen, um ein Podcast zu veröffentlichen.

01:08:12.940 --> 01:08:16.180
Und dann habe ich halt mein kleines Blog-Modul genommen,

01:08:16.480 --> 01:08:18.340
das ich mal irgendwann geschrieben habe

01:08:18.340 --> 01:08:22.800
und da jetzt auch so Podcast-Funktionalität reingedengelt.

01:08:23.100 --> 01:08:26.660
Und mal gucken, wie weit das trägt.

01:08:27.120 --> 01:08:29.940
aber das war alles gar nicht

01:08:29.940 --> 01:08:31.860
so schwierig. Also zum Beispiel, wo

01:08:31.860 --> 01:08:33.800
ein Django da schon sehr hilfbar ist,

01:08:33.800 --> 01:08:35.860
es gibt so ein

01:08:35.860 --> 01:08:37.780
Feed

01:08:37.780 --> 01:08:39.540
Syndication

01:08:39.540 --> 01:08:41.760
Feed App, also

01:08:41.760 --> 01:08:43.900
Django selbst enthält einige Apps, unter anderem

01:08:43.900 --> 01:08:45.460
halt Admin oder

01:08:45.460 --> 01:08:48.300
Contrib, Authentication

01:08:48.300 --> 01:08:48.780
und so Zeugs

01:08:48.780 --> 01:08:51.780
und halt auch ein Feed Syndication Framework,

01:08:51.860 --> 01:08:53.720
mit dem man halt Feeds generieren kann. Und das ist natürlich

01:08:53.720 --> 01:08:55.700
total hilfreich, wenn man das halt nicht selber

01:08:55.700 --> 01:08:57.020
machen muss, weil das ist irgendwie

01:08:57.020 --> 01:08:59.260
ziemlich fies.

01:09:00.320 --> 01:09:01.440
Und ja,

01:09:02.000 --> 01:09:03.660
das war eigentlich sehr

01:09:03.660 --> 01:09:04.760
angenehm. Was natürlich irgendwie

01:09:04.760 --> 01:09:07.420
immer noch ein Problem ist, ist, dass man dann halt

01:09:07.420 --> 01:09:09.720
irgendwie so diverse Feinheiten berücksichtigen muss.

01:09:09.840 --> 01:09:11.140
Man muss halt gucken, oh,

01:09:11.560 --> 01:09:12.320
wenn ich jetzt

01:09:12.320 --> 01:09:15.680
das auf dem eigentlich einzig relevanten

01:09:15.680 --> 01:09:19.660
Katalog, im einzig relevanten Katalog

01:09:19.660 --> 01:09:21.060
veröffentlichen will, das ist halt der iTunes

01:09:21.060 --> 01:09:23.740
Podcast, das iTunes Podcast

01:09:23.740 --> 01:09:25.680
Verzeichnis, dann gibt es halt noch

01:09:25.680 --> 01:09:27.740
so ein paar Spezialattribute,

01:09:27.860 --> 01:09:29.480
die halt iTunes haben will und die müssen halt

01:09:29.480 --> 01:09:31.480
irgendwie richtig gesetzt sein und das will halt die Bilder

01:09:31.480 --> 01:09:33.260
in einem bestimmten Format haben oder das

01:09:33.260 --> 01:09:34.540
Artwork zu dem Podcast.

01:09:35.720 --> 01:09:36.680
Und ja,

01:09:37.600 --> 01:09:39.520
Kategorien müssen ein bestimmtes Format

01:09:39.520 --> 01:09:40.180
haben und so Dinge.

01:09:41.280 --> 01:09:43.460
Da habe ich jetzt immer so ein bisschen knabbern müssen, aber

01:09:43.460 --> 01:09:45.380
so einfach nur, dass man dann

01:09:45.380 --> 01:09:47.340
RSS oder Atomfeed hat,

01:09:47.620 --> 01:09:48.740
wo die Episoden

01:09:48.740 --> 01:09:51.720
quasi drinstehen.

01:09:51.820 --> 01:09:53.100
Das war relativ einfach.

01:09:53.420 --> 01:09:55.320
Das war auch sowieso bei dem Blog-Teil

01:09:55.320 --> 01:09:57.260
war das halt sehr simpel. Das waren halt

01:09:57.260 --> 01:09:59.300
irgendwie, keine Ahnung, 15 Zeilen Code oder so

01:09:59.300 --> 01:10:01.660
und dann gab es ein RSS-Feed zu den

01:10:01.660 --> 01:10:02.520
Blogposts.

01:10:03.260 --> 01:10:05.160
Das heißt, wenn ihr euren eigenen Podcast machen könnt, könnt ihr

01:10:05.160 --> 01:10:06.860
jetzt demnächst Jochen das Modul dafür verwenden.

01:10:07.460 --> 01:10:08.500
Ja, kann man tatsächlich.

01:10:09.020 --> 01:10:11.160
Also sagen wir mal so, das ist halt nicht gut

01:10:11.160 --> 01:10:11.940
dokumentiert und

01:10:11.940 --> 01:10:15.260
wahrscheinlich alles irgendwie noch ein bisschen experimentell,

01:10:15.260 --> 01:10:17.400
aber so, ja, benutzen kann man

01:10:17.400 --> 01:10:19.600
das schon, wenn man

01:10:19.600 --> 01:10:21.400
ein bisschen

01:10:21.400 --> 01:10:22.320
furchtlos ist.

01:10:24.460 --> 01:10:26.260
ein Bastler

01:10:26.260 --> 01:10:28.240
ein bisschen was für Bastler, muss man schon sagen

01:10:28.240 --> 01:10:28.600
ja

01:10:28.600 --> 01:10:32.080
genau, und das ist natürlich dann auch eine

01:10:32.080 --> 01:10:33.920
Gutgelegenheit, um immer wieder was über

01:10:33.920 --> 01:10:35.980
Django zu erzählen, wenn da irgendwelche Probleme

01:10:35.980 --> 01:10:38.360
aufgetaucht sein sollten oder irgendwelche schönen

01:10:38.360 --> 01:10:40.300
eleganten Lösungen möglich werden

01:10:40.300 --> 01:10:41.380
ja

01:10:41.380 --> 01:10:43.240
also ich, ja

01:10:43.240 --> 01:10:46.200
ich bin da

01:10:46.200 --> 01:10:47.880
ich bin da eigentlich durchaus angetan, also auch die

01:10:47.880 --> 01:10:49.820
Erfahrungen irgendwie mit dem Blog

01:10:49.820 --> 01:10:52.100
Schreiben in Django, das war auch eigentlich alles sehr nett

01:10:52.100 --> 01:10:57.020
ja, man kann

01:10:57.020 --> 01:10:58.720
aber was auch interessant ist, ist halt

01:10:58.720 --> 01:11:01.060
ist es auf der einen Seite halt

01:11:01.060 --> 01:11:03.060
sehr, sehr viel da schon, was man

01:11:03.060 --> 01:11:05.100
verwenden kann, wenn man jetzt aber tiefer bohrt

01:11:05.100 --> 01:11:06.740
dann kommt man auch immer relativ schnell an

01:11:06.740 --> 01:11:09.020
Stellen, wo man sich sagt

01:11:09.020 --> 01:11:11.040
so, ja, da gibt es noch nichts, das hat noch

01:11:11.040 --> 01:11:13.040
nie jemand irgendwie und das ist

01:11:13.040 --> 01:11:15.020
halt schon so, also zum Beispiel bei

01:11:15.020 --> 01:11:16.380
den Bildern wieder, also

01:11:16.380 --> 01:11:19.000
vielleicht gibt es da auch was und ich weiß es einfach noch nicht

01:11:19.000 --> 01:11:20.540
das kann natürlich auch sein, aber

01:11:20.540 --> 01:11:25.360
dieses Django-Image-Kit löst in gewisser Weise

01:11:25.360 --> 01:11:27.480
ein Problem, halt dieses Vorberechnen

01:11:27.480 --> 01:11:29.620
der unterschiedlichen Bildgrößen.

01:11:30.300 --> 01:11:31.400
Aber wie es das tut, ist halt

01:11:31.400 --> 01:11:33.300
nicht so richtig toll. Und da gibt es dann wieder, soweit ich

01:11:33.300 --> 01:11:35.460
weiß, nix. Also es gibt

01:11:35.460 --> 01:11:37.360
da ja tolle Möglichkeiten. Es gibt so

01:11:37.880 --> 01:11:40.900
LibJPG-Turbo oder

01:11:40.900 --> 01:11:43.340
Mods.jpg, die

01:11:43.340 --> 01:11:45.500
halt ungefähr nochmal so mindestens

01:11:45.500 --> 01:11:47.500
ein Drittel die Bilder

01:11:47.500 --> 01:11:49.460
kleiner machen bei gleicher Qualität oder auch

01:11:49.460 --> 01:11:51.440
dafür sorgen, dass wenn ein Bild angezeigt wird

01:11:51.440 --> 01:11:53.380
und das geladen wird, dann werden halt zuerst grobe

01:11:53.380 --> 01:11:55.340
Geschichten angezeigt und dann halt feinere

01:11:55.340 --> 01:11:57.520
Sachen. Das kann man mit JPEG

01:11:57.520 --> 01:11:58.380
halt irgendwie machen.

01:11:59.540 --> 01:12:00.940
Und ja,

01:12:01.300 --> 01:12:05.120
defaultmäßig wird aber Pillow verwendet.

01:12:05.180 --> 01:12:07.480
Pillow verwendet irgendwie unten drunter Image Magic oder so.

01:12:08.160 --> 01:12:09.300
Und das ist alles

01:12:09.300 --> 01:12:11.400
nicht richtig optimal. Also da kann man zwar angeben,

01:12:11.640 --> 01:12:13.180
wie hoch die Qualität sein soll,

01:12:13.860 --> 01:12:15.240
aber die Bilder

01:12:15.240 --> 01:12:16.980
sind halt nicht so klein, wie sie sein könnten, was

01:12:16.980 --> 01:12:19.160
für die meisten Leute vielleicht kein großes

01:12:19.160 --> 01:12:21.220
Problem sein wird, aber wenn man jetzt irgendwie ein paar tausend

01:12:21.220 --> 01:12:23.040
Bilder hat, dann macht das durchaus was aus.

01:12:23.420 --> 01:12:25.120
Oder ich hab mal so ein, ich hab auch

01:12:25.120 --> 01:12:27.080
einen Blog mit relativ vielen Bildern

01:12:27.080 --> 01:12:28.840
drin und war dann irgendwie,

01:12:29.000 --> 01:12:31.100
dann hörte ich immer so Klagen von Leuten,

01:12:31.140 --> 01:12:33.360
die sich das angeguckt haben. Das dauert

01:12:33.360 --> 01:12:35.120
immer so lange. Ich hab das gar nicht so gemerkt.

01:12:35.240 --> 01:12:37.080
Gut, ich hab hier irgendwie so 100M mit, was jetzt auch nicht so

01:12:37.080 --> 01:12:39.000
furchtbar schnell ist, aber da ging das eigentlich ganz flüssig.

01:12:39.960 --> 01:12:41.340
Und dann hab ich halt immer so in den

01:12:41.340 --> 01:12:43.360
D-Blog-Truber

01:12:43.360 --> 01:12:45.040
geguckt und so und gesehen so,

01:12:45.080 --> 01:12:47.300
oh, wir so die ersten fünf Artikel

01:12:47.300 --> 01:12:49.100
holen mit vielen Bildern drin. Das sind halt so

01:12:49.100 --> 01:12:51.220
200 MB. Wenn man sich das auf dem Handy

01:12:51.220 --> 01:12:53.200
auf Edge anguckt, dann könnte ich mir durchaus vorstellen,

01:12:53.320 --> 01:12:54.520
dass es ein bisschen langsam ist.

01:12:57.640 --> 01:12:57.860
Ja,

01:12:58.240 --> 01:13:00.720
und da wäre es schon schön, wenn man da

01:13:00.720 --> 01:13:03.240
tatsächlich quasi Default-mäßig

01:13:03.240 --> 01:13:04.520
auch irgendwie

01:13:04.520 --> 01:13:07.180
gute Ergebnisse bekommt, aber das ist halt

01:13:07.180 --> 01:13:09.040
irgendwie momentan

01:13:09.040 --> 01:13:11.180
jedenfalls noch nicht so. Und da wäre es natürlich auch interessant, wenn da

01:13:11.180 --> 01:13:13.000
also man

01:13:13.000 --> 01:13:15.080
stößt relativ schnell auf Ecken, wo man

01:13:15.080 --> 01:13:17.120
eigentlich was verbessern könnte, wenn man dann mal Zeit hat.

01:13:17.380 --> 01:13:21.440
tja. Johannes, wo ist dein größter

01:13:21.440 --> 01:13:21.900
Struggle?

01:13:24.120 --> 01:13:24.400
Das

01:13:24.400 --> 01:13:27.240
ist wie beim Jochen, das sind die Details.

01:13:28.540 --> 01:13:29.260
Man kommt

01:13:29.260 --> 01:13:31.360
sehr schnell so zu den

01:13:31.360 --> 01:13:33.160
95 Prozent des Projektes,

01:13:33.420 --> 01:13:35.300
die eigentlich so smooth sailing

01:13:35.300 --> 01:13:37.180
sind, die man

01:13:37.180 --> 01:13:38.640
am ersten Tag durchkriegt

01:13:38.640 --> 01:13:41.000
und an den letzten 5 Prozent arbeitet man dann

01:13:41.000 --> 01:13:41.800
die nächsten zwei Jahre.

01:13:42.060 --> 01:13:47.160
Es ist schwierig zu sagen, welcher Bereich

01:13:47.160 --> 01:13:49.040
am schwierigsten ist, weil es eben oft

01:13:49.040 --> 01:13:51.240
an diesen ganz kleinen Details hängen bleibt.

01:13:52.680 --> 01:13:53.280
Hast du da was

01:13:53.280 --> 01:13:55.000
selber für gebaut, was du irgendwo

01:13:55.000 --> 01:13:56.400
mal offengestellt hast?

01:13:57.140 --> 01:13:59.040
Es gibt so ein paar Sachen, die ich mal

01:13:59.040 --> 01:14:00.140
gebaut habe und offengestellt habe.

01:14:00.140 --> 01:14:00.680
Erzähl mal.

01:14:01.680 --> 01:14:03.380
Die sind alle schon etwas älter.

01:14:06.080 --> 01:14:07.980
Die meisten Sachen, die ich in den letzten Jahren

01:14:07.980 --> 01:14:09.840
gemacht habe, waren eben für Kunden und dann

01:14:09.840 --> 01:14:11.820
ist es schwierig, denen zu sagen,

01:14:11.980 --> 01:14:14.100
ich habe so und so viele Stunden

01:14:14.100 --> 01:14:16.180
dafür abgerechnet, wie wäre es,

01:14:16.260 --> 01:14:18.120
wir das jetzt der Welt für umsonst geben.

01:14:19.020 --> 01:14:20.180
Deshalb sind die meisten Sachen, die ich

01:14:20.180 --> 01:14:21.760
in den letzten Jahren gemacht habe, eben hinter

01:14:21.760 --> 01:14:23.740
Gittern. Die müssen leider hinter Gittern bleiben.

01:14:26.340 --> 01:14:28.000
Eine Sache, die ich vor Jahren mal in Python

01:14:28.000 --> 01:14:30.080
gemacht habe, ist eine Bibliothek

01:14:30.080 --> 01:14:31.780
für Kommandozeilenaufrufe.

01:14:31.860 --> 01:14:33.600
Hat jetzt überhaupt gar nichts mit Django zu tun.

01:14:35.620 --> 01:14:36.100
Verlinken wir

01:14:36.100 --> 01:14:37.360
natürlich auch in den Show noch. Natürlich.

01:14:37.540 --> 01:14:40.080
Kommandier heißt die Bibliothek. Beste Kommandozeilen-Bibliothek,

01:14:40.160 --> 01:14:40.460
die es gibt.

01:14:43.200 --> 01:14:43.980
Weil es einfach

01:14:43.980 --> 01:14:46.100
ein Problem war, was mich gestört hat. Ich wollte gerne

01:14:46.100 --> 01:14:48.720
einfache Programme mit der Kommandozeile

01:14:48.720 --> 01:14:50.600
ansprechen oder eine ansprechende

01:14:50.600 --> 01:14:52.000
Kommandozeile anbieten können.

01:14:52.940 --> 01:14:54.540
Und die Lösungen, die es gab, haben mich alle nicht

01:14:54.540 --> 01:14:55.960
überzeugt, also habe ich meine eigene gemacht.

01:14:58.500 --> 01:15:00.400
Das ist so ein bisschen das, was

01:15:00.400 --> 01:15:02.420
von einem erwartet wird und was man

01:15:02.420 --> 01:15:03.640
natürlich dann auch gerne macht,

01:15:04.540 --> 01:15:06.400
weil man ja nicht der Einzige ist, der

01:15:06.400 --> 01:15:07.300
dieses Problem hat.

01:15:08.200 --> 01:15:10.540
Vor Jahren hat der Python Package Index

01:15:10.540 --> 01:15:12.180
immer noch Downloadzahlen angezeigt

01:15:12.180 --> 01:15:14.360
und die sahen

01:15:14.360 --> 01:15:16.420
eigentlich schon immer ganz gut aus für meine kleine

01:15:16.420 --> 01:15:18.420
Bibliothek. Inzwischen zeigen sie die nicht mehr an.

01:15:19.820 --> 01:15:20.300
Ich weiß also

01:15:20.300 --> 01:15:22.080
nicht, wie viele Leute das verwenden oder nicht.

01:15:24.020 --> 01:15:24.560
Aber so ein kleines

01:15:24.560 --> 01:15:26.120
bisschen Validierung kriegt man da schon

01:15:26.120 --> 01:15:27.660
von der Gemeinde zurück.

01:15:28.460 --> 01:15:30.540
Klingt spannend, sehr schon nutzlich.

01:15:31.900 --> 01:15:32.000
Ja.

01:15:33.580 --> 01:15:34.280
Da haben wir noch

01:15:34.280 --> 01:15:35.940
ein bisschen Schleichwerbung gemacht für die

01:15:35.940 --> 01:15:37.800
Open-Source-Pakete hier. Ich bin begeistert.

01:15:38.960 --> 01:15:40.200
Ja, für kostenlose Dinge

01:15:40.200 --> 01:15:41.420
Werbung machen ist

01:15:41.420 --> 01:15:42.860
nicht so schlimm.

01:15:44.360 --> 01:15:47.280
genau. Was fällt euch denn noch

01:15:47.280 --> 01:15:49.120
zu Django ein? Haben wir noch irgendwas bei den Themen

01:15:49.120 --> 01:15:51.200
offen, was vergessen? Irgendwie was von Tipps und Tricks,

01:15:51.360 --> 01:15:53.300
die gerade noch so unter den Fingern

01:15:53.300 --> 01:15:55.320
brennen, die ihr gerade noch mitbekommen habt?

01:15:55.860 --> 01:15:57.280
Ah, so viele. Es gibt so viele

01:15:57.280 --> 01:15:58.880
Sachen. Wir könnten, glaube ich, tagelang

01:15:58.880 --> 01:16:01.020
über Django und über die

01:16:01.020 --> 01:16:03.240
verschiedenen Bauteile reden und was jetzt

01:16:03.240 --> 01:16:05.320
besser ist und was schlechter ist,

01:16:05.420 --> 01:16:07.380
dass es mir echt schwerfällt, eine Auswahl

01:16:07.380 --> 01:16:09.160
zu treffen. Ja doch, vielleicht eine Geschichte,

01:16:09.160 --> 01:16:11.380
die ich, Tests

01:16:11.380 --> 01:16:12.800
sind ja eine relativ wichtige

01:16:12.800 --> 01:16:14.340
Geschichte und

01:16:14.340 --> 01:16:17.040
Der ist jemand wach geworden.

01:16:17.100 --> 01:16:19.380
Ja, und wütend.

01:16:20.440 --> 01:16:20.740
Naja.

01:16:23.320 --> 01:16:25.180
Auf jeden Fall, dass du über Tests sprichst.

01:16:25.180 --> 01:16:27.440
Ja, das ist immer sehr schmerzhaft.

01:16:27.580 --> 01:16:29.440
Da kommt tatsächlich direkt ein Kreis hoch.

01:16:30.520 --> 01:16:31.100
Ja, genau.

01:16:31.500 --> 01:16:32.620
Und da gibt es

01:16:32.620 --> 01:16:34.460
also ich bin da

01:16:34.460 --> 01:16:36.600
ein Fan von PyTest,

01:16:36.880 --> 01:16:39.020
eher als von dem eingebauten Unit-Test

01:16:39.020 --> 01:16:40.440
Framework in Python und

01:16:40.440 --> 01:16:43.160
da gibt es dann auch diverse

01:16:43.160 --> 01:16:45.980
Hilfspakete, die einem das erleichtern.

01:16:47.420 --> 01:16:47.940
Irgendwie

01:16:47.940 --> 01:16:48.720
zum Beispiel

01:16:48.720 --> 01:16:51.680
PyTestJungle oder PyTestSugar

01:16:51.680 --> 01:16:52.380
und

01:16:52.380 --> 01:16:55.880
diverse andere. Und dann gibt es

01:16:55.880 --> 01:16:57.340
noch Dinge, die einem irgendwie so

01:16:57.340 --> 01:16:58.800
erleichtern, so ein bisschen

01:16:58.800 --> 01:17:01.400
Fixtures und Daten zu generieren,

01:17:01.540 --> 01:17:02.980
so Factory Boy und

01:17:02.980 --> 01:17:06.020
weiß ich

01:17:06.020 --> 01:17:07.720
gar nicht, was man da, ob man das

01:17:07.720 --> 01:17:09.460
wirklich alles empfehlen sollte, was ich da so verwende.

01:17:10.440 --> 01:17:14.800
und genau, das ist eigentlich

01:17:14.800 --> 01:17:16.720
auch sehr praktisch. Also da gibt es halt

01:17:16.720 --> 01:17:18.740
dann schon eine existierende Integration, da muss man

01:17:18.740 --> 01:17:19.820
sich gar nicht so

01:17:19.820 --> 01:17:22.680
selbst drum kümmern und

01:17:22.680 --> 01:17:24.460
das

01:17:24.460 --> 01:17:26.660
funktioniert eigentlich echt ganz toll.

01:17:27.420 --> 01:17:27.520
Also

01:17:27.520 --> 01:17:30.620
ich weiß nicht, ich glaube, du machst eher Unit-Test

01:17:30.620 --> 01:17:32.800
oder das klassische? Ja, ich benutze

01:17:32.800 --> 01:17:34.760
eher die in Django eingebauten, also

01:17:34.760 --> 01:17:36.700
die klassischen Unit-Tests. Ich mag Py-Test

01:17:36.700 --> 01:17:37.180
nicht so gerne.

01:17:39.920 --> 01:17:42.080
Aber da gibt es doch Methodennamen

01:17:42.080 --> 01:17:43.120
mit CamelCase.

01:17:44.280 --> 01:17:45.200
Ja, muss man ja nicht.

01:17:45.540 --> 01:17:45.960
Muss man nicht?

01:17:46.140 --> 01:17:49.020
Nee, alles, was Test- heißt, ist ein Test.

01:17:49.200 --> 01:17:50.320
Und alles andere ist egal.

01:17:51.500 --> 01:17:51.740
Hm.

01:17:52.720 --> 01:17:53.960
Nee, das ist ganz normal.

01:17:54.500 --> 01:17:56.280
Dieser Testrunner ist nicht besonders gut.

01:17:56.380 --> 01:17:57.700
Ich benutze immer den Nose-Testrunner,

01:17:57.820 --> 01:17:59.580
aber das ist nur eine Kleinigkeit.

01:18:00.360 --> 01:18:01.840
Ja, und man muss so Dinge machen wie,

01:18:01.900 --> 01:18:04.080
man muss sagen, AssertEqual.

01:18:04.300 --> 01:18:06.280
Da hat man doch auch wieder CamelCase irgendwie.

01:18:07.200 --> 01:18:08.200
Ja, das stimmt.

01:18:08.280 --> 01:18:10.480
diese Assert-Methoden sind so ein bisschen seltsam.

01:18:10.480 --> 01:18:14.760
Aber das sind so Dinge, an die gewöhnt man sich mit der Zeit.

01:18:14.840 --> 01:18:16.820
Und dann erscheinen sie einem völlig undenkbar,

01:18:17.020 --> 01:18:18.340
dass es anders sein könnte.

01:18:21.340 --> 01:18:22.440
Und ich glaube auch,

01:18:22.480 --> 01:18:26.540
wir haben kein grundsätzliches Missverständnis zwischen uns.

01:18:27.800 --> 01:18:29.120
Man sollte Tests schreiben.

01:18:29.140 --> 01:18:30.100
Ihr habt ja beide schon brav eure Tests gemacht.

01:18:30.100 --> 01:18:33.060
Natürlich, Coverage ist hoch genug.

01:18:35.000 --> 01:18:38.220
Und ob die Assert-Methode jetzt Assert-Equal heißt

01:18:38.220 --> 01:18:39.800
oder assert equals oder assert

01:18:39.800 --> 01:18:41.500
unterstrich equal oder was weiß ich, wie sie

01:18:41.500 --> 01:18:43.320
bei PyTest heißen mag.

01:18:43.400 --> 01:18:45.600
Es ist einfach nur assert. Dann sagt man

01:18:45.600 --> 01:18:47.600
irgendwie das eine gleich gleich das andere

01:18:47.600 --> 01:18:49.580
oder so. Ja, das kannst du aber

01:18:49.580 --> 01:18:50.960
im Unitest prinzipiell auch machen.

01:18:51.640 --> 01:18:53.640
Aber dann kannst du halt nicht unterscheiden zwischen

01:18:53.640 --> 01:18:55.600
du wolltest, dass da ein Fehler passiert

01:18:55.600 --> 01:18:56.880
oder du wolltest nicht, dass ein Fehler passiert.

01:18:57.600 --> 01:18:59.640
Aber das sind auch da wieder nur

01:18:59.640 --> 01:19:01.660
Detailthemen, ob das jetzt so oder so

01:19:01.660 --> 01:19:03.140
ausschaut.

01:19:03.840 --> 01:19:05.300
Ist, glaube ich, gar nicht so wichtig.

01:19:05.960 --> 01:19:06.060
Ja.

01:19:07.260 --> 01:19:08.640
Aber wir kehren

01:19:08.640 --> 01:19:10.280
wieder zurück zu diesem Thema, was wir vorhin

01:19:10.280 --> 01:19:12.540
hatten. Jeder hat so seine Präferenzen

01:19:12.540 --> 01:19:14.580
und mit der Zeit findet man halt

01:19:14.580 --> 01:19:16.040
so die Sachen, die man am liebsten benutzt.

01:19:16.120 --> 01:19:18.340
Die ausgelatschten Wege, die immer tiefer werden,

01:19:18.400 --> 01:19:20.500
weil man immer wieder durchstiefelt. Und dann kann man nie wieder

01:19:20.500 --> 01:19:21.280
was Neues anfangen.

01:19:23.820 --> 01:19:24.380
Ich hoffe,

01:19:24.520 --> 01:19:26.520
dass wir uns genügend Flexibilität erhalten haben,

01:19:26.720 --> 01:19:28.300
um doch immer noch neue Sachen

01:19:28.300 --> 01:19:30.300
anfangen zu können. Immer neu lernen,

01:19:30.380 --> 01:19:32.380
heißt ja auch ganz wenig Wissen und immer

01:19:32.380 --> 01:19:33.300
wieder von neu anfangen.

01:19:34.800 --> 01:19:36.340
Ganz, ganz wenig Wissen, weiß ich nicht,

01:19:36.380 --> 01:19:37.700
ob das so eine super Idee ist.

01:19:38.360 --> 01:19:40.360
Naja, man kann sich mal wieder neue Bausteine suchen.

01:19:40.920 --> 01:19:42.840
Ach ja, viel Software, die man so kennt,

01:19:43.120 --> 01:19:43.780
fühlt sich schon so an,

01:19:43.840 --> 01:19:46.960
als ob die einfach mit ganz wenig Wissen gestartet ist.

01:19:49.300 --> 01:19:50.520
Das stimmt natürlich auch.

01:19:51.080 --> 01:19:53.500
Aber was man generell sagen kann,

01:19:53.600 --> 01:19:54.460
ist also testen, testen, testen.

01:19:54.480 --> 01:20:12.980
Und wenn man das nicht macht, das ist eine sehr gute Idee. Ich habe früher immer gedacht, ich bin halt eher so jemand, der mehr so auf der, ich habe früher eher Backend oder ich komme ganz ursprünglich aus der Systemadministration und dann irgendwie über Datenbanken und dann bin ich immer weiter in dieses Programmieren reingerutscht.

01:20:14.000 --> 01:20:35.300
Aber am Anfang habe ich irgendwie eher kurze Sachen geschrieben und fand das immer viel einfacher, wenn das irgendwie so Skripte waren, die nur so auf einer Bildschirmseite passen oder vielleicht ein paar hundert Zeilen haben oder so, das war, da habe ich mich wohl gefühlt, weil das war etwas, was kann man halt so komplett überblicken und wenn da sich irgendwas dran ändern soll, dann kann man das auch tun, ohne dass es hinterher schief geht.

01:20:35.840 --> 01:20:38.040
Und immer, wenn ich dann versucht habe, größere Sachen zu schreiben

01:20:38.040 --> 01:20:40.140
und dann halt Features hinter sehr

01:20:40.140 --> 01:20:41.880
dazukamen oder sich geändert haben,

01:20:42.040 --> 01:20:44.240
dann sind immer furchtbare Sachen passiert. Oder nicht immer,

01:20:44.420 --> 01:20:46.540
aber häufig genug,

01:20:46.660 --> 01:20:47.380
dass es irgendwie

01:20:47.380 --> 01:20:49.260
unangenehm war,

01:20:49.780 --> 01:20:51.200
schreckliche Dinge passiert.

01:20:51.660 --> 01:20:52.800
Die Welt geht unangenehm, ja.

01:20:53.580 --> 01:20:55.760
Ja, und seit

01:20:55.760 --> 01:20:58.040
ich irgendwie Tests schreibe, ist das

01:20:58.040 --> 01:20:59.620
eigentlich nicht mehr so schlimm.

01:21:01.300 --> 01:21:01.740
Seitdem

01:21:01.740 --> 01:21:02.840
nicht mehr so schlimm.

01:21:02.860 --> 01:21:04.740
Das passiert leider immer noch.

01:21:05.260 --> 01:21:07.180
So ganz lässt sich das nicht verhindern, aber

01:21:07.180 --> 01:21:08.360
es ist,

01:21:09.660 --> 01:21:11.320
ich fühle mich jetzt wohl dabei, auch

01:21:11.320 --> 01:21:13.360
längere Sachen zu schreiben, auch wenn ich jetzt nicht

01:21:13.360 --> 01:21:15.140
mehr quasi die Details anderer

01:21:15.140 --> 01:21:17.640
Module

01:21:17.640 --> 01:21:19.580
oder anderer Apps, die

01:21:19.580 --> 01:21:21.080
da auch noch Dinge tun,

01:21:21.240 --> 01:21:23.280
wenn ich die nicht mehr so verstehe oder auch lange nicht mehr

01:21:23.280 --> 01:21:25.280
daran gearbeitet habe, dann habe ich jetzt nicht mehr

01:21:25.280 --> 01:21:27.180
so ein Problem, irgendwas zu ändern, was die betrifft.

01:21:27.320 --> 01:21:29.380
Wenn ich hinterher die Tests durchlaufen lasse und

01:21:29.380 --> 01:21:31.380
die sehen gut aus, dann kann ich

01:21:31.380 --> 01:21:33.500
ja schon relativ sicher sein, dass da nichts total Schreckliches

01:21:33.500 --> 01:21:34.040
passieren wird.

01:21:35.380 --> 01:21:37.300
Und wenn man das halt nicht hat, dann

01:21:37.300 --> 01:21:39.000
hat man ein großes Problem, weil

01:21:39.000 --> 01:21:41.440
wenn man Tests hat, dann weiß man, wenn man ein Update

01:21:41.440 --> 01:21:43.600
macht oder wenn man jetzt eine Version von einer Bibliothek

01:21:43.600 --> 01:21:45.340
ändert oder man ändert irgendwas völlig

01:21:45.340 --> 01:21:47.780
harmloses, von dem her man denkt, das kann eigentlich überhaupt keine Auswirkungen

01:21:47.780 --> 01:21:49.500
auf irgendwas anderes haben und dann

01:21:49.500 --> 01:21:51.440
füllt man die Tests aus und dann schlagen vier Tests Fail

01:21:51.440 --> 01:21:53.500
und einer davon schlägt Fail und man denkt sich so

01:21:53.500 --> 01:21:55.300
oh Gott, das hätte nie passieren dürfen.

01:21:56.360 --> 01:21:57.220
Dann weiß man,

01:21:58.340 --> 01:21:59.460
ja, das wäre jetzt, wenn man keine

01:21:59.460 --> 01:22:01.600
Tests gehabt hätte, dann wäre das ein wirklich fieser

01:22:01.600 --> 01:22:03.480
Bug gewesen und teilweise

01:22:03.480 --> 01:22:05.120
sind die halt so, dass man sich hinterher auch sagt,

01:22:05.680 --> 01:22:07.380
also da kommt man nicht drauf, dass

01:22:07.380 --> 01:22:08.960
das irgendwie die Auswirkungen hatte, das

01:22:08.960 --> 01:22:10.920
hätte man jetzt gar nicht,

01:22:11.560 --> 01:22:13.480
also durch lange Meditationen über diese

01:22:13.480 --> 01:22:14.920
Änderungen hätte man das nicht wirklich

01:22:14.920 --> 01:22:17.160
rausbekommen können und

01:22:17.160 --> 01:22:19.320
wäre ihm wahrscheinlich auch gar nicht aufgefallen und dann

01:22:19.320 --> 01:22:20.920
irgendwann fliegt es dann im, ja.

01:22:21.140 --> 01:22:23.160
Wäre es dem User aufgefallen oder

01:22:23.160 --> 01:22:25.340
dann hätte der sich beschwert, was

01:22:25.340 --> 01:22:27.320
schon ziemlich schlimm ist oder noch schlimmer

01:22:27.320 --> 01:22:29.180
es wäre irgendwie eine Sicherheitslücke oder so gewesen, also

01:22:29.180 --> 01:22:32.960
Also man fühlt sich da deutlich besser,

01:22:33.180 --> 01:22:36.680
wenn man Tests hat und das irgendwie so praktiziert.

01:22:36.800 --> 01:22:38.600
Und seit ich damit angefangen habe,

01:22:39.220 --> 01:22:42.320
fühle ich mich da irgendwie deutlich wohler mit allem.

01:22:45.000 --> 01:22:48.580
Also, ihr hört, brav testen und eure Tests fern benutzen.

01:22:49.160 --> 01:22:50.400
Verschreibt ihr denn zuerst eure Tests

01:22:50.400 --> 01:22:51.480
oder schreibt ihr erst den Code?

01:22:53.560 --> 01:22:55.440
Da kann man sich, wenn man die Frage beantwortet,

01:22:55.480 --> 01:22:56.660
kann man sich nur in den Nesseln setzen.

01:22:57.520 --> 01:22:59.440
Weil du so viele Zusendungen kriegst,

01:22:59.540 --> 01:23:00.600
dass man es anders machen sollte.

01:23:01.020 --> 01:23:02.560
Zusendungen übrigens gerne an

01:23:02.560 --> 01:23:04.640
hallo-podcast.de

01:23:04.640 --> 01:23:06.960
Du könntest jederzeit Fragen, Anmerkungen stellen.

01:23:07.280 --> 01:23:08.740
Ich habe gerade so wunderschön reingepasst.

01:23:10.320 --> 01:23:11.940
Keine Aussage von dir, Johannes?

01:23:12.320 --> 01:23:13.600
Ich schreibe meinen Code zuerst

01:23:13.600 --> 01:23:14.660
und schreibe die Tests hinterher.

01:23:14.980 --> 01:23:16.780
Und das schockiert viele Leute.

01:23:17.840 --> 01:23:18.900
Ich mache nicht TDD.

01:23:19.220 --> 01:23:21.080
Ich komme überhaupt gar nicht klar mit TDD.

01:23:21.920 --> 01:23:23.280
TDD ist Test Driven Development.

01:23:23.560 --> 01:23:24.920
Genau, Test Driven Development heißt,

01:23:25.620 --> 01:23:33.340
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.

01:23:34.660 --> 01:23:38.760
Und die Idee dahinter ist eben, dass man immer automatisch 100% Test Coverage hat.

01:23:38.760 --> 01:23:44.760
Alles, was man an Code geschrieben hat, ist automatisch getestet, weil man den Test vorher geschrieben hat, bevor man den Code geschrieben hat.

01:23:44.860 --> 01:23:45.560
Klingt logisch.

01:23:45.940 --> 01:23:46.420
Klingt logisch.

01:23:47.060 --> 01:23:51.680
Das Problem für mich ist, dass Tests sind etwas,

01:23:52.400 --> 01:23:54.200
auch wie der Jochen das soeben beschrieben hat,

01:23:54.860 --> 01:23:57.620
die fixieren die Funktionalität eines Programms.

01:23:57.920 --> 01:24:00.440
Die sorgen dafür, dass ich weiß,

01:24:00.520 --> 01:24:02.520
das funktioniert genau auf diese Art und Weise.

01:24:04.100 --> 01:24:06.660
Ich weiß aber oft gar nicht, wie ein Programm funktionieren soll,

01:24:06.720 --> 01:24:07.740
wenn ich anfange, das zu schreiben.

01:24:07.740 --> 01:24:10.660
Und dann fällt es mir sehr schwer, diesen Test dafür zu schreiben,

01:24:11.280 --> 01:24:13.620
wenn ich noch gar nicht weiß, wie ich es dann tatsächlich machen möchte.

01:24:14.060 --> 01:24:16.020
Wie ich denn möchte, dass es am Ende ausschaut.

01:24:17.060 --> 01:24:30.540
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.

01:24:30.860 --> 01:24:39.100
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?

01:24:40.740 --> 01:24:59.440
Nee, ich glaube, es ist einfach nur ein gewisser Arbeitsmodus, der eben zu manchen Leuten passt und der zu manchen Leuten nicht passt. Und ich bin immer sehr beeindruckt, wenn Leute TDD machen und wenn die das zeigen und ich weiß auch, dass das super gut funktioniert, weil die Vorteile eben da sind.

01:24:59.440 --> 01:25:01.600
man hat eben immer Tests

01:25:01.600 --> 01:25:03.620
geschrieben, bevor man Code überhaupt

01:25:03.620 --> 01:25:05.840
schreibt. Also aller Code, den man schreibt, ist getestet

01:25:05.840 --> 01:25:07.580
automatisch. Heißt auch nicht,

01:25:07.760 --> 01:25:09.820
dass der 100% failsafe

01:25:09.820 --> 01:25:11.580
ist, aber man kann auf jeden Fall sicher sein, dass die

01:25:11.580 --> 01:25:13.320
Dinge, die man in die Tests geschrieben hat, so funktionieren.

01:25:14.220 --> 01:25:15.280
Wie sie funktionieren sollen.

01:25:16.460 --> 01:25:17.100
Wie machst du das, Jochen?

01:25:18.280 --> 01:25:19.480
Ich muss gestehen, tatsächlich

01:25:19.480 --> 01:25:20.920
genauso quasi.

01:25:22.440 --> 01:25:22.680
Also,

01:25:22.920 --> 01:25:25.620
ja, ich habe ja auch schon häufiger mal, oder ich habe es auch tatsächlich

01:25:25.620 --> 01:25:27.580
schon probiert, irgendwie zuerst die Tests zu schreiben und dann

01:25:27.580 --> 01:25:28.180
den Code, aber

01:25:28.180 --> 01:25:30.700
also es gibt da eben

01:25:30.700 --> 01:25:33.360
zwei Dinge für mich. Also eine Sache ist halt

01:25:33.360 --> 01:25:35.360
auch, dass ich oft

01:25:35.360 --> 01:25:37.160
nicht weiß, wo es hingehen soll und

01:25:37.160 --> 01:25:39.320
ich fange sogar, das ist auch vielleicht noch

01:25:39.320 --> 01:25:40.400
eine ganz interessante Empfehlung,

01:25:41.120 --> 01:25:43.200
oft auch gar nicht jetzt

01:25:43.200 --> 01:25:45.400
tatsächlich ein Modul

01:25:45.400 --> 01:25:47.000
anzuschreiben, wenn ich irgendwas schreibe.

01:25:47.260 --> 01:25:49.420
Also quasi in einer Django-App

01:25:49.420 --> 01:25:51.140
so ein Django-Projekt oder

01:25:51.140 --> 01:25:53.260
eine Django-Applikation besteht üblicherweise

01:25:53.260 --> 01:25:54.940
aus einer Reihe von Django-Apps, die man halt schreibt

01:25:54.940 --> 01:25:57.080
und dann gibt es halt Third-Party-Apps, die man sich von irgendwo

01:25:57.080 --> 01:25:59.000
importiert, wenn man es installiert hat

01:25:59.000 --> 01:26:00.420
und dann gibt es halt welche, die man selber schreibt.

01:26:01.060 --> 01:26:02.120
Also User-Verwaltung ist

01:26:02.120 --> 01:26:04.940
üblicherweise ein Teil und dann kann halt

01:26:04.940 --> 01:26:06.320
irgendwie, keine Ahnung,

01:26:06.780 --> 01:26:08.900
ein bestimmter Teil der Webseite kann halt irgendwie ein anderer Teil

01:26:08.900 --> 01:26:09.520
sein oder so.

01:26:11.920 --> 01:26:12.240
Und

01:26:12.240 --> 01:26:14.900
üblicherweise schreibt man halt in diesen Apps

01:26:14.900 --> 01:26:16.640
irgendwas, wenn man jetzt eine Django

01:26:16.640 --> 01:26:18.060
Applikation schreibt.

01:26:18.580 --> 01:26:20.560
Aber oft, wenn ich nicht weiß,

01:26:20.880 --> 01:26:22.740
wie ich überhaupt irgendwas

01:26:22.740 --> 01:26:24.540
machen möchte, dann mache ich nicht das, sondern

01:26:24.540 --> 01:26:26.500
ich schreibe Sachen in einem Notebook.

01:26:27.080 --> 01:26:30.060
Das ist

01:26:30.060 --> 01:26:33.220
Das ist auch der Hintergrund, der da durchkommt.

01:26:33.300 --> 01:26:35.060
Ja, ja, natürlich. Also ich mache halt

01:26:35.060 --> 01:26:37.140
eher so eigentlich

01:26:37.140 --> 01:26:39.300
noch mehr als Django

01:26:39.300 --> 01:26:40.200
so Data Science.

01:26:40.800 --> 01:26:43.720
Du meinst ein Jupyter-Notebook? Genau, ein Jupyter-Notebook.

01:26:44.640 --> 01:26:45.380
Da gibt es auch

01:26:45.380 --> 01:26:47.040
ein sehr

01:26:47.040 --> 01:26:48.360
empfehlenswertes Paket, nennt sich

01:26:48.360 --> 01:26:50.460
Django Extensions.

01:26:51.480 --> 01:26:52.920
Da sind einige schöne Sachen dabei.

01:26:53.560 --> 01:26:54.960
Unter anderem halt ein Entwicklungsserver,

01:26:55.260 --> 01:26:57.820
eingebauten Debugger hat, wo man dann halt direkt

01:26:57.820 --> 01:26:59.780
im Traceback quasi eine Debug-Shell bekommt.

01:27:01.980 --> 01:27:03.620
Da gibt es

01:27:03.620 --> 01:27:05.860
noch andere Dinge, Shell Plus, wo dann halt

01:27:05.860 --> 01:27:07.220
diverse Imports schon mit drin sind.

01:27:08.040 --> 01:27:09.920
Was das Ding auch hat, ist, man kann

01:27:09.920 --> 01:27:10.280
halt

01:27:10.280 --> 01:27:13.880
Shell Plus minus minus Notebook oder so

01:27:13.880 --> 01:27:16.120
starten und dann wird ein Notebook-Server hochgefahren

01:27:16.120 --> 01:27:17.580
und zwar mit einer Django-Shell.

01:27:17.720 --> 01:27:19.940
Und dann hat man halt all den Kram, den man in Shell Plus hat,

01:27:20.420 --> 01:27:21.660
halt in einem Jupyter-Notebook.

01:27:21.860 --> 01:27:23.780
Und das ist halt sehr nett. Und dann kann man halt einfach mal

01:27:23.780 --> 01:27:25.820
eingehen und mit den Dingen spielen und einfach mal

01:27:25.820 --> 01:27:27.920
so Sachen so sketchmäßig

01:27:27.920 --> 01:27:29.260
implementieren und gucken, ob es funktioniert.

01:27:29.720 --> 01:27:31.480
Und erst, wenn ich weiß, okay, so

01:27:31.480 --> 01:27:33.660
funktioniert das irgendwie, was ich vorhabe,

01:27:34.260 --> 01:27:35.680
schreibe ich das quasi tatsächlich

01:27:35.680 --> 01:27:37.580
in eine Django-App rein

01:27:37.580 --> 01:27:39.760
und gut,

01:27:39.900 --> 01:27:41.640
es gibt Dinge, bei denen geht es nicht anders.

01:27:41.800 --> 01:27:43.420
Jetzt, wenn man... Oh, Gesundheit.

01:27:43.620 --> 01:27:43.940
Ja, danke.

01:27:45.400 --> 01:27:47.360
Wenn man Modelle hat und die Datenbank

01:27:47.360 --> 01:27:49.640
ändert sich, dann muss man das halt

01:27:49.640 --> 01:27:51.420
irgendwie in der Models-PY machen

01:27:51.420 --> 01:27:53.140
und dann muss man halt irgendwie Migrationen ausführen.

01:27:53.780 --> 01:27:55.500
Oh, Migration, das ist ja auch so ein Thema.

01:27:58.460 --> 01:28:01.480
Aber wenn es um irgendwie Logik oder so geht,

01:28:02.520 --> 01:28:03.720
dass die richtig funktioniert

01:28:03.720 --> 01:28:05.860
oder man einfach nur hinkriegen möchte,

01:28:06.020 --> 01:28:08.220
dass das jetzt, oder wie man das elegant hinschreibt,

01:28:08.260 --> 01:28:10.040
man weiß oft nicht, wie man das elegant hinschreibt.

01:28:10.580 --> 01:28:11.880
Und wenn man Sachen ausprobiert,

01:28:11.940 --> 01:28:13.260
dafür ist ein Notebook echt total super.

01:28:13.780 --> 01:28:15.540
Kann man halt so lange probieren, bis es geht.

01:28:15.700 --> 01:28:18.400
Muss nicht dauernd irgendwie sich darum kümmern,

01:28:18.600 --> 01:28:20.460
dass man auf der Webseite ist, irgendwas anklickt

01:28:20.460 --> 01:28:22.680
oder irgendwie den Entwicklungsserver neu startet,

01:28:22.740 --> 01:28:24.500
beim Syntax-Error steigt der dann aus und dann muss man

01:28:24.500 --> 01:28:25.240
wieder neu starten.

01:28:27.100 --> 01:28:28.320
Das ist alles so ein bisschen langsam

01:28:28.320 --> 01:28:29.840
und im Notebook ist das alles viel schneller.

01:28:30.500 --> 01:28:32.420
Und dann, wenn das halt irgendwie funktioniert, dann übertrage ich

01:28:32.420 --> 01:28:34.500
die Funktionen, die ich halt im Notebook drinstehen habe,

01:28:34.580 --> 01:28:35.440
halt in meine

01:28:35.440 --> 01:28:37.600
anderen Files und dann

01:28:37.600 --> 01:28:40.200
schreibe ich Tests halt irgendwie.

01:28:41.620 --> 01:28:41.940
Das ist

01:28:41.940 --> 01:28:44.620
der eine Punkt. Der andere Punkt bei Tests ist halt,

01:28:44.620 --> 01:28:46.560
dass es Dinge gibt, die sind

01:28:46.560 --> 01:28:48.560
sehr schwer zu testen. Es bringt aber gar nicht

01:28:48.560 --> 01:28:50.420
so furchtbar viel, das zu testen. Also das ist

01:28:50.420 --> 01:28:52.260
auch sowas. Wenn man jetzt tatsächlich,

01:28:52.420 --> 01:28:54.760
ich habe auch eigentlich fast nie 100% Testabdeckung,

01:28:54.900 --> 01:28:56.580
sondern meistens eher so 70

01:28:56.580 --> 01:28:57.480
bis 80 oder so.

01:28:59.120 --> 01:29:00.740
Was auch

01:29:00.740 --> 01:29:02.560
nicht so schlecht ist, was halt, ja, es ist halt irgendwo,

01:29:02.940 --> 01:29:04.540
ich weiß nicht genau, wo der Sweetspot ist,

01:29:04.720 --> 01:29:06.220
vielleicht ist er bei noch ein bisschen mehr, vielleicht ist er bei

01:29:06.220 --> 01:29:07.240
ein bisschen weniger.

01:29:09.160 --> 01:29:10.620
Ich finde, es ist halt

01:29:10.620 --> 01:29:12.580
im Grunde wichtig, dass man so viele Tests hat,

01:29:12.660 --> 01:29:14.480
dass einem, wenn was schief geht, das auffällt,

01:29:14.840 --> 01:29:16.500
aber wenn man jetzt so viel

01:29:16.500 --> 01:29:18.620
Tests hat, auch wenn man so viel

01:29:18.620 --> 01:29:20.600
Zeit in den Tests verbringt, hat man halt das Problem, dass man

01:29:20.600 --> 01:29:22.580
sich dann schon sehr, sehr festgelegt hat und das hinterher schwer

01:29:22.580 --> 01:29:23.100
ändern kann.

01:29:25.400 --> 01:29:26.740
Und die Frage ist, ist es das wert?

01:29:27.040 --> 01:29:28.620
Wenn das halt gar nicht mehr so viele Fehler

01:29:28.620 --> 01:29:30.100
fängt, weil ich irgendwie anfange,

01:29:31.120 --> 01:29:32.720
weiß ich nicht, also Dinge, die ich selten teste,

01:29:32.920 --> 01:29:34.720
sind halt, funktioniert das URL-Routing?

01:29:34.940 --> 01:29:36.600
Das kriege ich eigentlich auch ohne Tests mit,

01:29:36.640 --> 01:29:37.540
wenn das nicht mehr funktioniert.

01:29:38.980 --> 01:29:40.560
Oder auch die Tests schlagen halt

01:29:40.560 --> 01:29:41.840
Fehler, die auf die entsprechenden Endpunkte gehen.

01:29:43.340 --> 01:29:44.740
Oder das Django-Admin

01:29:44.740 --> 01:29:46.560
Geschichten, die teste ich auch

01:29:46.560 --> 01:29:47.620
eigentlich eher selten.

01:29:48.520 --> 01:29:50.560
Also die Logik schon,

01:29:50.600 --> 01:29:52.620
aber nicht, ob Ant-Admin überhaupt geht.

01:29:52.720 --> 01:29:54.400
Überhaupt sollte man nicht unbedingt testen,

01:29:54.420 --> 01:29:56.460
die halt schon eigene Pakete sind, weil die haben schon

01:29:56.460 --> 01:29:56.980
Tests und so.

01:29:58.840 --> 01:30:00.340
Und für mich ist

01:30:00.340 --> 01:30:02.300
der Sweet Spot beim Testen eher so bei

01:30:02.300 --> 01:30:03.340
70, 80 Prozent.

01:30:05.580 --> 01:30:06.520
Ein Test,

01:30:06.920 --> 01:30:08.520
die man einfach schreiben kann.

01:30:08.560 --> 01:30:10.540
Das ist ja auch immer so ein Problem, wenn die Tests zu kompliziert werden.

01:30:11.400 --> 01:30:12.540
Also gut, manchmal schaffe ich

01:30:12.540 --> 01:30:14.360
das nicht. Manchmal schreibe ich auch Tests, die komplizierte

01:30:14.360 --> 01:30:16.120
Dinge tun und dann hinterher ärgere ich mich immer,

01:30:16.220 --> 01:30:18.420
wenn die fehlschlagen und ich dann nicht mehr

01:30:18.420 --> 01:30:20.100
weiß, was testet das überhaupt?

01:30:20.220 --> 01:30:21.040
Warum brauchst du Dinge?

01:30:21.740 --> 01:30:23.000
Was macht das für komische Sachen?

01:30:23.380 --> 01:30:24.660
Du brauchst Tests für deine Tests.

01:30:25.720 --> 01:30:27.360
Genau, und das will man natürlich eigentlich vermeiden,

01:30:27.480 --> 01:30:31.320
weil dann wird es schwer.

01:30:31.740 --> 01:30:33.320
Wie kriege ich überhaupt so eine Test-Coverage raus?

01:30:33.540 --> 01:30:34.260
Also woher weiß ich denn,

01:30:34.360 --> 01:30:36.240
wie viel von meiner Funktion getestet wird?

01:30:36.760 --> 01:30:37.880
Zähle ich dann einfach die Funktionen,

01:30:37.900 --> 01:30:39.180
schreibe für jede Funktion eine Test-Funktion

01:30:39.180 --> 01:30:41.640
und gucke dann und dividiere dann in Quotienten?

01:30:42.020 --> 01:30:43.300
Ja, da gibt es Tools für.

01:30:43.300 --> 01:30:46.320
Also da gibt es ein Tool, das heißt Coverage.

01:30:47.200 --> 01:30:48.120
Ein kreativer Name.

01:30:48.460 --> 01:30:50.480
der gibt einem im Wesentlichen für jede Programmzeile

01:30:50.480 --> 01:30:52.500
an, würde die von einem Test berührt

01:30:52.500 --> 01:30:54.200
oder nicht. Und

01:30:54.200 --> 01:30:56.520
die Anzahl der Gesamtzeilen in einem Programm

01:30:56.520 --> 01:30:58.400
geteilt durch die Anzahl der getesteten

01:30:58.400 --> 01:30:59.960
Zeilen. Okay, also ganz easy.

01:31:00.140 --> 01:31:02.340
Ganz easy. Das macht einmal eine

01:31:02.340 --> 01:31:04.300
Ausgabe auf der Commando-Zeile, aber es

01:31:04.300 --> 01:31:06.040
macht halt auch, es erzeugt so irgendwie HTML

01:31:06.040 --> 01:31:08.300
und wenn man das im Browser aufmacht,

01:31:08.520 --> 01:31:09.560
dann, wenn man auf die

01:31:09.560 --> 01:31:12.100
entsprechende Zeile drückt, dann sieht man halt auch

01:31:12.100 --> 01:31:14.240
eine Ansicht des Codes und sieht

01:31:14.240 --> 01:31:16.120
dann halt irgendwie farblich markiert, welche

01:31:16.120 --> 01:31:18.300
Codezeilen halt noch nicht getestet sind.

01:31:18.300 --> 01:31:20.300
und dann kann man halt relativ schnell sehen, wenn das halt Zeugs

01:31:20.300 --> 01:31:22.220
ist, wo man relativ sicher davon

01:31:22.220 --> 01:31:23.760
ausgehen kann, dass es sowieso funktionieren wird, wie

01:31:23.760 --> 01:31:26.260
URL-Confs oder... Die Stereo-Methode.

01:31:26.480 --> 01:31:28.200
Ja, dann muss man...

01:31:28.200 --> 01:31:29.940
Jedes Modell hat eine Stereo-Methode und das

01:31:29.940 --> 01:31:32.120
wird nie auf 100% Coverage, wenn man diese

01:31:32.120 --> 01:31:33.980
Methode nicht testet, aber die ist völlig irrelevant.

01:31:34.400 --> 01:31:34.500
Ja.

01:31:36.020 --> 01:31:38.060
Auf der anderen Seite, wenn man dann halt durchscrollt und sieht dann

01:31:38.060 --> 01:31:39.260
halt irgendwie ein komplexes

01:31:39.260 --> 01:31:41.760
Ding, ein Algorithmus, der irgendwas macht

01:31:41.760 --> 01:31:43.900
und der ist gar nicht getestet, dann sollte man

01:31:43.900 --> 01:31:45.420
da sollte man dann vielleicht mal einen Test schreiben.

01:31:46.060 --> 01:31:48.000
Und so kann man, so gehe ich jedenfalls vor. Ich gucke mir halt

01:31:48.000 --> 01:31:49.780
immer an, was die größten Code-Teile, die halt am meisten

01:31:49.780 --> 01:31:52.060
Funktionalität irgendwie haben. Wenn die nicht geteilt

01:31:52.060 --> 01:31:52.920
sind, dann fange ich halt da an.

01:31:55.700 --> 01:31:57.820
Es gibt auch ganz viele IDEs, die das integrieren,

01:31:58.200 --> 01:32:00.080
wo du quasi diese Ansicht in der IDE hast.

01:32:00.260 --> 01:32:01.980
Wenn du eine Testansicht haben kannst, wo du

01:32:01.980 --> 01:32:03.560
eben siehst, welche Zeilen durchgelaufen sind.

01:32:03.680 --> 01:32:05.820
Welche IDE nutzt du? Ich benutze

01:32:05.820 --> 01:32:06.340
PyCharm.

01:32:08.660 --> 01:32:09.620
Vor ein paar Jahren

01:32:09.620 --> 01:32:11.660
sind die plötzlich groß

01:32:11.660 --> 01:32:12.380
geworden.

01:32:14.460 --> 01:32:15.420
JetBrains ist

01:32:15.420 --> 01:32:17.100
so eine Variante von

01:32:17.100 --> 01:32:18.740
von einer IDE, die hieß

01:32:18.740 --> 01:32:19.640
früher IDEA.

01:32:20.880 --> 01:32:22.640
Die gibt es auch immer noch. Das ist eine Java-IDE.

01:32:25.420 --> 01:32:26.920
Es ist schwierig, da eine Empfehlung

01:32:26.920 --> 01:32:29.120
zu geben, weil auch da die Vorlieben sehr weit...

01:32:29.120 --> 01:32:30.860
Deine Vorliebe hat natürlich auch Interesse.

01:32:31.100 --> 01:32:33.000
Genau. Und es ist auch eine Gewöhnung.

01:32:33.240 --> 01:32:35.080
Ich weiß auch, dass es nicht die beste IDE

01:32:35.080 --> 01:32:36.880
ist und ich weiß auch, dass sie nicht

01:32:36.880 --> 01:32:37.980
ungeheuer billig ist.

01:32:39.380 --> 01:32:39.740
Aber

01:32:39.740 --> 01:32:42.340
ich benutze halt das, was ich gewöhnt bin.

01:32:42.600 --> 01:32:44.040
Also Community Edition kann man vergessen.

01:32:44.040 --> 01:32:45.920
Die Community Edition kann man nehmen, aber die hat

01:32:45.920 --> 01:32:47.160
nicht so eine gute Django-Integration.

01:32:47.560 --> 01:32:49.580
Gerade was Django angeht, ist tatsächlich

01:32:49.580 --> 01:32:51.680
die Professional Edition deutlich besser, weil

01:32:51.680 --> 01:32:53.840
die viele von den Sachen,

01:32:53.960 --> 01:32:55.580
die in Django so ein bisschen implizit

01:32:55.580 --> 01:32:57.120
sind, trotzdem weiß.

01:32:58.480 --> 01:32:59.640
Gerade was die

01:32:59.640 --> 01:33:01.440
Datenbank angeht, ist da sehr viel drin.

01:33:01.820 --> 01:33:03.600
Oder Templates auch. Die Template-Syntax

01:33:03.600 --> 01:33:05.360
ist in der Community Edition nicht drin.

01:33:06.520 --> 01:33:07.340
Ist ein bisschen schade,

01:33:08.440 --> 01:33:09.460
aber so ist es normalerweise.

01:33:12.700 --> 01:33:13.540
Migration hast du noch

01:33:13.540 --> 01:33:15.400
angesprochen, Jürgen. Ja, ja,

01:33:15.500 --> 01:33:18.520
Das ist auch etwas, was halt...

01:33:18.520 --> 01:33:19.140
Was ist das?

01:33:19.520 --> 01:33:20.180
Genau, was ist das?

01:33:20.320 --> 01:33:22.020
Also oft hat man halt das Problem,

01:33:23.240 --> 01:33:25.560
wenn man jetzt so eine Applikation entwickelt,

01:33:25.740 --> 01:33:27.540
man hat ein neues Feature oder so

01:33:27.540 --> 01:33:29.940
und dafür muss man jetzt auch das Datenmodell ändern,

01:33:30.240 --> 01:33:32.120
weil man irgendwas Neues abspeichern muss oder so.

01:33:33.280 --> 01:33:35.540
Oder man muss halt eine bestehende Datenstruktur irgendwie ändern,

01:33:35.680 --> 01:33:37.840
weil sich die Beziehungen der Daten untereinander irgendwie ändern oder so.

01:33:38.660 --> 01:33:40.720
Und dann ist die Frage, wie macht man das eigentlich?

01:33:42.720 --> 01:33:44.560
Das gab es in den ersten Versionen von Django,

01:33:44.740 --> 01:33:47.040
gab es das nicht. Da konnte man Datenbanken

01:33:47.040 --> 01:33:48.720
nicht ändern. Du musst dann mal manuell

01:33:48.720 --> 01:33:50.200
ändern in der Datenbank selber

01:33:50.200 --> 01:33:52.620
oder halt einmal komplett resetten.

01:33:54.940 --> 01:33:56.460
Ja, genau.

01:33:56.600 --> 01:33:58.260
Dann gab es irgendwann

01:33:58.260 --> 01:34:00.740
ein Modul,

01:34:00.820 --> 01:34:01.760
das nannte sich South.

01:34:02.600 --> 01:34:03.960
Das hat dann damit angefangen.

01:34:04.080 --> 01:34:07.240
Ich weiß gar nicht, wo die Idee dafür herkommt.

01:34:07.800 --> 01:34:08.500
Für den Namen?

01:34:09.760 --> 01:34:10.700
Einmal für den Namen nicht.

01:34:10.820 --> 01:34:11.560
Und ich weiß auch gar nicht, wo das...

01:34:11.560 --> 01:34:14.060
Das ist, glaube ich, Vogelmigration, dass die in den Süden ziehen.

01:34:14.160 --> 01:34:16.020
Ach so, Vogelmigration.

01:34:16.540 --> 01:34:17.900
Ja, schlau.

01:34:19.300 --> 01:34:20.820
Ist nur ein bisschen schlecht, wenn man danach googeln will.

01:34:21.200 --> 01:34:22.820
Ja, es ist eher Django South.

01:34:24.040 --> 01:34:26.460
Jedenfalls, diese Bibliothek hat dieses Problem gelöst,

01:34:26.600 --> 01:34:28.060
in dem man eben gesagt hat,

01:34:28.140 --> 01:34:31.880
okay, ich möchte jetzt eine Zustandsänderung aufzeichnen.

01:34:33.000 --> 01:34:33.820
Und diese Zustandsänderung,

01:34:34.480 --> 01:34:36.900
die konnte man dann auf eine Datenbank anwenden.

01:34:37.200 --> 01:34:38.840
Also die hat einfach tatsächlich diese Tabellen,

01:34:38.980 --> 01:34:41.100
die da drin sind, verändert.

01:34:41.260 --> 01:34:42.420
Die haben ein Alter Table gemacht

01:34:42.420 --> 01:34:44.340
oder Zeilen gelöscht

01:34:44.340 --> 01:34:46.160
oder was auch immer notwendig war,

01:34:46.300 --> 01:34:48.140
um eben diesen neuen Datenbankzustand

01:34:48.140 --> 01:34:50.140
hinzubekommen. Nicht den Datenzustand,

01:34:50.260 --> 01:34:52.000
also nicht, was da in der Datenbank drin ist, sondern die

01:34:52.000 --> 01:34:54.000
Struktur, die strukturelle

01:34:54.000 --> 01:34:55.320
Anlage der Datenbank.

01:34:56.120 --> 01:34:57.980
Und das ist so ein wichtiges Problem,

01:34:58.080 --> 01:35:00.060
dass es irgendwann in Django Core gewandert ist

01:35:00.060 --> 01:35:02.200
und ist jetzt eines der wichtigsten Module

01:35:02.200 --> 01:35:03.560
in Django. Ja, ja, auf jeden Fall.

01:35:04.500 --> 01:35:05.720
Also ich erinnere mich da auch

01:35:05.720 --> 01:35:08.180
mit

01:35:08.180 --> 01:35:10.120
Schrecken an Zeiten,

01:35:10.120 --> 01:35:10.360
also

01:35:10.360 --> 01:35:14.760
wo dieses Problem, also jetzt

01:35:14.760 --> 01:35:16.700
mit integrierten Migrationen und so

01:35:16.700 --> 01:35:18.620
ist es halbwegs okay, also es ist auch immer noch

01:35:18.620 --> 01:35:20.580
ein Stößer auf viele Fälle, wo es

01:35:20.580 --> 01:35:22.840
eklig werden kann und wo man auch für die Migration

01:35:22.840 --> 01:35:24.060
dann Tests schreiben muss und so,

01:35:24.640 --> 01:35:26.760
aber wenn ich mich da

01:35:26.760 --> 01:35:28.720
an frühere Zeiten zurückerinnere,

01:35:29.000 --> 01:35:30.640
wo wir jetzt gar nicht sowas wie Django verwendet hatten,

01:35:30.740 --> 01:35:31.140
zum Beispiel

01:35:31.140 --> 01:35:34.700
bei Firmen, bei denen ich gearbeitet habe, sondern

01:35:34.700 --> 01:35:36.540
irgendwie selbstgebaute

01:35:36.540 --> 01:35:38.240
Webframeworks

01:35:38.240 --> 01:35:40.860
oder Dinge, die es schon gab, die aber

01:35:40.860 --> 01:35:43.000
sowas alles nicht drin hatten, da war

01:35:43.000 --> 01:35:44.580
das immer irgendwie

01:35:44.580 --> 01:35:46.800
eine problematische Geschichte. Da hat man

01:35:46.800 --> 01:35:47.900
dann halt irgendwie

01:35:47.900 --> 01:35:51.100
das getestet, irgendwie lokal

01:35:51.100 --> 01:35:53.380
oder auf einem Entwicklungssystem oder einem Staging-System

01:35:53.380 --> 01:35:54.900
und hat das dann funktioniert.

01:35:55.060 --> 01:35:56.620
Dann hat man das Problem, wie synchronisiert man die

01:35:56.620 --> 01:35:58.580
unterschiedlichen Schema-Versionen, was

01:35:58.580 --> 01:36:00.480
passiert auf dem Produktionssystem,

01:36:00.780 --> 01:36:00.960
dann

01:36:00.960 --> 01:36:04.680
hat man das irgendwie durchgeführt und dann ist auf dem

01:36:04.680 --> 01:36:06.660
Produktionssystem aber was anderes passiert, als man

01:36:06.660 --> 01:36:08.620
irgendwie eigentlich erwartet hatte und dann

01:36:08.620 --> 01:36:10.540
musste man halt wieder nachgucken, was ist denn da

01:36:10.540 --> 01:36:12.380
jetzt eigentlich passiert und es gab gar keine

01:36:12.380 --> 01:36:14.540
formalisierte Sicht

01:36:14.540 --> 01:36:16.640
auf dieses, was passiert

01:36:16.640 --> 01:36:18.680
da jetzt gerade, sondern das ist halt ein Skript, das man ausgeführt

01:36:18.680 --> 01:36:19.700
hat und dann

01:36:19.700 --> 01:36:22.600
ja, das ist dann aber

01:36:22.600 --> 01:36:23.980
möglicherweise auch nicht

01:36:23.980 --> 01:36:26.380
so mit dabei,

01:36:26.620 --> 01:36:28.380
sondern das ist bei irgendeinem Entwickler auf dem Rechner

01:36:28.380 --> 01:36:30.340
und so und der connectiert sich halt

01:36:30.340 --> 01:36:33.160
in irgendeinem Notebook und das

01:36:33.160 --> 01:36:33.800
macht dann halt irgendwas

01:36:33.800 --> 01:36:37.440
und das ist halt schön, wenn man das halt formalisiert hat,

01:36:37.520 --> 01:36:39.440
weil bei Django hat man dann halt irgendwie ein Verzeichnis

01:36:39.440 --> 01:36:41.320
Migrations, in dem die alle dringend liegen, wo man

01:36:41.320 --> 01:36:43.580
reingucken kann, was da passiert, in der Datenbank

01:36:43.580 --> 01:36:45.380
selbst wird festgehalten, welche schon

01:36:45.380 --> 01:36:47.460
ausgeführt worden sind und an welcher Stelle man

01:36:47.460 --> 01:36:49.460
sich befindet und man kann halt auch leicht wieder

01:36:49.460 --> 01:36:51.460
vor- und zurückspulen sozusagen, man kann

01:36:51.460 --> 01:36:53.400
halt sagen, migrate

01:36:53.400 --> 01:36:55.680
und dann halt eine Nummer einer Migration

01:36:55.680 --> 01:36:57.480
angeben, zu der man zurück möchte und

01:36:57.480 --> 01:36:59.640
dann rollt sich die Datenbank in diesen Zustand

01:36:59.640 --> 01:37:01.600
wieder zurück, dann kann man halt, wenn man

01:37:01.600 --> 01:37:03.360
zum Beispiel gesehen hat, dass das, was man gemacht hat, war

01:37:03.360 --> 01:37:05.400
Blödsinn, dann rollt man halt das Ding

01:37:05.400 --> 01:37:07.300
zurück, löscht die Migration und macht halt eine andere

01:37:07.300 --> 01:37:09.440
und ja, das

01:37:09.440 --> 01:37:11.300
ist eine sehr, sehr praktische Geschichte und

01:37:11.300 --> 01:37:13.300
führt halt dazu, dass man dieses ganze

01:37:13.300 --> 01:37:15.100
Problem irgendwie so halbwegs in den Griff

01:37:15.100 --> 01:37:17.060
bekommt und es gibt

01:37:17.060 --> 01:37:19.200
zumindest die Tools an die Hand, mit denen man das in den Griff

01:37:19.200 --> 01:37:21.240
bekommen kann, was halt

01:37:21.240 --> 01:37:22.740
in

01:37:22.740 --> 01:37:25.080
wenn man das halt nicht so macht, sondern

01:37:25.080 --> 01:37:27.060
von Hand oder selbst gestrickt halt

01:37:27.060 --> 01:37:29.160
doch viele böse Falschtricke

01:37:29.160 --> 01:37:31.140
für Leute bereithält und die dann

01:37:31.140 --> 01:37:32.640
also relativ unvorbereitet reinlaufen

01:37:32.640 --> 01:37:35.920
und das ist halt eine Geschichte, die man auf jeden Fall

01:37:35.920 --> 01:37:36.900
wissen sollte, dass das gibt

01:37:36.900 --> 01:37:39.520
Ich glaube auch, dass gerade

01:37:39.520 --> 01:37:41.840
Third-Party-Apps dadurch überhaupt erst richtig

01:37:41.840 --> 01:37:43.720
möglich wurden, dass man eben diese

01:37:43.720 --> 01:37:45.860
Migrationen mitliefern konnte, weil

01:37:45.860 --> 01:37:47.600
sonst immer in jeder

01:37:47.600 --> 01:37:49.940
Bibliotheks-Update musstest du

01:37:49.940 --> 01:37:51.600
von Hand diese Struktur anpassen

01:37:51.600 --> 01:37:54.020
oder eben diese Skripte haben, die das irgendwie

01:37:54.020 --> 01:37:56.220
machen und hoffen, dass die funktionieren auf deiner Datenbank

01:37:56.220 --> 01:37:57.840
genauso wie sie bei dem

01:37:57.840 --> 01:37:58.760
Entwickler funktioniert haben

01:37:58.760 --> 01:38:02.260
und heute weißt du einfach, wenn du eine Bibliothek installierst

01:38:02.260 --> 01:38:04.360
die bringt ihre Migration mit und die funktionieren auch.

01:38:06.900 --> 01:38:08.260
Aber klar, es ist auch so ein

01:38:08.260 --> 01:38:10.200
Fallstrick, wenn man zum ersten Mal

01:38:10.200 --> 01:38:12.280
eine Django-Anwendung startet und dann schön seine

01:38:12.280 --> 01:38:13.520
Modelle geschrieben hat und dann

01:38:13.520 --> 01:38:16.400
Operational Errors bekommt, weil die Datenbank nicht da ist.

01:38:18.720 --> 01:38:20.320
Stolper ich auch regelmäßig noch drüber,

01:38:20.560 --> 01:38:22.360
weil ich vergesse, meine Datenbank

01:38:22.360 --> 01:38:22.840
zu migrieren.

01:38:24.960 --> 01:38:26.360
Dann gibt es keine automatische

01:38:26.360 --> 01:38:28.340
Erinnerung, also die musst du dir dann selber...

01:38:28.340 --> 01:38:30.240
Der Operational Error ist die automatische Erinnerung.

01:38:32.260 --> 01:38:33.480
Ja, das hört sich auf jeden Fall so an.

01:38:33.580 --> 01:38:34.920
Da könnte man Django für alles mögliche

01:38:34.920 --> 01:38:37.220
einsetzen. Für große Projekte,

01:38:37.300 --> 01:38:39.320
für kleine Projekte, für schmale, schlanke.

01:38:40.040 --> 01:38:41.140
Ich weiß nicht, haben wir eigentlich schon

01:38:41.140 --> 01:38:42.480
irgendwelche Beispiele genannt für

01:38:42.480 --> 01:38:45.460
Django-Anwendungen, die man vielleicht so

01:38:45.460 --> 01:38:46.560
kennt? Kennst du denn welche?

01:38:46.840 --> 01:38:48.120
Ja, ist ja zufällig.

01:38:48.900 --> 01:38:50.760
Ich kenne bestimmt auch nicht alle, aber ich glaube,

01:38:51.340 --> 01:38:52.800
eine der größten Django

01:38:52.800 --> 01:38:55.140
Implementationen

01:38:56.080 --> 01:38:56.720
hat Instagram

01:38:56.720 --> 01:38:58.960
oder hat Instagram? Aber haben sie abgelöst.

01:38:58.960 --> 01:39:00.980
Haben sie abgelöst? Oh je, dann war das jetzt kein

01:39:00.980 --> 01:39:03.740
Nee, aber sie sind natürlich sehr groß damit gewachsen.

01:39:04.520 --> 01:39:07.960
Und das ist natürlich richtig.

01:39:09.220 --> 01:39:10.700
Was machen die denn jetzt, weißt du das?

01:39:11.100 --> 01:39:11.980
Weiß ich nicht genau, nee.

01:39:13.340 --> 01:39:18.340
Es ist üblicherweise so, dass wenn man solche Standardlösungen einsetzt

01:39:18.340 --> 01:39:20.240
und dann so groß wird wie Instagram zum Beispiel,

01:39:20.940 --> 01:39:22.780
dass man dann auf einmal auf Probleme trifft,

01:39:23.080 --> 01:39:25.360
die eben durch Standardlösungen nicht mehr abgedeckt werden

01:39:25.360 --> 01:39:29.060
und dass man dann anfängt, seine eigenen Dinge zu bauen.

01:39:29.640 --> 01:39:30.940
Das haben die ganzen großen Firmen

01:39:30.940 --> 01:39:32.780
machen das ja alle. Die betreiben alle ihre eigenen

01:39:32.780 --> 01:39:34.780
Web-Server. Die haben alle ihre

01:39:34.780 --> 01:39:36.760
eigenen Datenbanken geschrieben. Die haben alle ihre eigene

01:39:36.760 --> 01:39:38.780
Infrastruktur geschrieben, weil ab einer gewissen Größe

01:39:38.780 --> 01:39:40.420
sind die Standardlösungen einfach nicht mehr wichtig.

01:39:40.560 --> 01:39:42.680
Und bei Instagram war es genauso. Die sind sehr

01:39:42.680 --> 01:39:44.560
groß geworden mit Django und haben es dann abgelöst.

01:39:45.200 --> 01:39:45.740
Soweit ich weiß.

01:39:47.280 --> 01:39:48.860
Fällt dir noch ein anderes Beispiel ein?

01:39:49.220 --> 01:39:49.900
Einem von euch?

01:39:50.760 --> 01:39:52.420
Es gibt viele kleine Sachen,

01:39:53.340 --> 01:39:54.540
die damit laufen.

01:39:56.360 --> 01:39:56.960
Man sieht

01:39:56.960 --> 01:39:58.620
das von außen natürlich nicht. Man sieht in der

01:39:58.620 --> 01:40:00.760
Web-Anwendung nicht an, ob es in Django geschrieben ist

01:40:00.760 --> 01:40:01.120
oder nicht.

01:40:01.480 --> 01:40:04.620
Und deshalb muss man

01:40:04.620 --> 01:40:06.560
so ein bisschen darauf vertrauen, dass

01:40:06.560 --> 01:40:07.900
die Entwickler einem das mitteilen.

01:40:09.260 --> 01:40:10.300
Es gibt ein System, das heißt

01:40:10.300 --> 01:40:12.520
Pre-Tix. Das ist ein

01:40:12.520 --> 01:40:14.440
Ticket-Verkaufssystem. Also wenn man

01:40:14.440 --> 01:40:16.220
ein Konzert veranstaltet und Tickets verkaufen möchte,

01:40:16.960 --> 01:40:18.540
das ist in Django geschrieben. Die sind auch

01:40:18.540 --> 01:40:19.120
sehr aktiv

01:40:19.120 --> 01:40:22.100
bei den Django-Cons.

01:40:24.380 --> 01:40:24.580
Ja.

01:40:25.860 --> 01:40:26.680
Ne, ansonsten,

01:40:26.740 --> 01:40:27.840
also ich weiß das halt auch noch.

01:40:28.380 --> 01:40:29.300
Das ist so eine Zeitung in Amerika.

01:40:29.380 --> 01:40:29.760
Ja, genau.

01:40:32.760 --> 01:40:36.800
Das waren die ursprünglichen Entwickler von Django.

01:40:36.920 --> 01:40:38.500
Also es kommt aus dem Zeitungsumfeld.

01:40:40.320 --> 01:40:44.840
Also auch als Blog-Plattform für Vertrieb von neuen News-Artikeln?

01:40:45.300 --> 01:40:49.980
Ja, die haben ihre komplette Zeitungs-Webseite damit organisiert im Wesentlichen.

01:40:49.980 --> 01:40:53.820
Also so ist es, das ist so die Entstehungsgeschichte.

01:40:54.060 --> 01:40:56.500
Das ist aus einer kleinen Stadt in Texas, Lawrence.

01:40:58.380 --> 01:41:00.220
wo eben zwei Entwickler gesagt haben, wir machen das

01:41:00.220 --> 01:41:01.760
jetzt einmal richtig, anstatt immer wieder

01:41:01.760 --> 01:41:03.440
PHP-Kram zusammenzubasteln.

01:41:04.840 --> 01:41:06.280
Haben sie einmal das Problem richtig

01:41:06.280 --> 01:41:08.140
gelöst und durften es dann irgendwann

01:41:08.140 --> 01:41:10.100
veröffentlichen. Und das System

01:41:10.100 --> 01:41:12.300
heißt jetzt Django. Und soweit ich weiß,

01:41:12.360 --> 01:41:13.160
wird es da immer noch eingesetzt.

01:41:16.120 --> 01:41:16.560
Spannend.

01:41:17.420 --> 01:41:18.340
Ja, habt ihr

01:41:18.340 --> 01:41:20.040
noch was beizutragen zum Django oder

01:41:20.040 --> 01:41:22.480
würdet ihr sagen, wir haben das Thema jetzt so weit

01:41:22.480 --> 01:41:23.500
durch?

01:41:25.420 --> 01:41:26.220
Es gibt noch

01:41:26.220 --> 01:41:28.360
viele Dinge, die man machen könnte, aber nichts Konkretes.

01:41:29.180 --> 01:41:31.560
Wenn wir irgendein Thema nochmal besprechen sollen,

01:41:31.660 --> 01:41:33.800
dann sag gerne Bescheid, dann machen wir genau

01:41:33.800 --> 01:41:35.960
da weiter. Es gibt ja auch diese E-Mail-Adresse,

01:41:36.100 --> 01:41:37.580
an die man Fragen schicken kann. Genau,

01:41:37.720 --> 01:41:39.580
hallo at python-podcast.de

01:41:39.580 --> 01:41:40.540
Ja.

01:41:42.520 --> 01:41:43.800
Ne, mir fällt da

01:41:43.800 --> 01:41:44.520
jetzt auch tatsächlich,

01:41:46.260 --> 01:41:47.700
man kann bestimmt auch noch

01:41:47.700 --> 01:41:48.440
über diverse

01:41:48.440 --> 01:41:51.800
Bereiche in

01:41:51.800 --> 01:41:53.740
Django wieder eine eigene Sendung

01:41:53.740 --> 01:41:54.780
machen. Ja, eigene Episoden.

01:41:55.140 --> 01:41:57.680
Episode über den ORM oder Episode über

01:41:57.680 --> 01:41:59.620
Template-Sprachen oder so. Ja, oder auch

01:41:59.620 --> 01:42:02.140
über ganz einfache Sachen wie die Formular-Integration

01:42:02.140 --> 01:42:03.700
oder wie

01:42:03.700 --> 01:42:05.300
die Session-Integration oder

01:42:05.300 --> 01:42:07.640
ganz einfache Dinge, die

01:42:07.640 --> 01:42:08.620
man so für

01:42:08.620 --> 01:42:11.640
ganz normal hält, die aber

01:42:11.640 --> 01:42:13.480
für euch ist alles ganz normal,

01:42:13.660 --> 01:42:16.100
easy und aus dem Ärmel.

01:42:16.100 --> 01:42:17.620
Man kriegt das halt automatisch mit.

01:42:17.780 --> 01:42:20.040
Wenn man Django einmal startet, dann ist es schon da

01:42:20.040 --> 01:42:21.560
und man muss sich nie Gedanken darüber machen.

01:42:21.840 --> 01:42:23.940
Aber es ist super interessant, was damit alles geht

01:42:23.940 --> 01:42:25.980
und was vielleicht nicht geht und wie

01:42:25.980 --> 01:42:27.760
es geht. Und

01:42:27.760 --> 01:42:28.920
super spannende Sachen.

01:42:29.840 --> 01:42:31.920
Was man vielleicht noch erwähnen sollte, also dieser ganze

01:42:31.920 --> 01:42:33.860
Web-Stack, also Web ist halt so ein bisschen

01:42:33.860 --> 01:42:36.080
was man halt leider

01:42:36.080 --> 01:42:38.060
auch immer wieder sieht, dass es nicht so richtig

01:42:38.060 --> 01:42:39.860
aus einem Guss, also wenn man sich jetzt

01:42:39.860 --> 01:42:42.040
beispielsweise anschaut, wenn man mit Xcode

01:42:42.040 --> 01:42:44.380
jetzt iOS-Applikationen

01:42:44.380 --> 01:42:45.980
erstellt oder so, dann ist das halt

01:42:45.980 --> 01:42:47.920
auch Model-View-Controller, aber es ist halt

01:42:47.920 --> 01:42:49.420
eigentlich sehr

01:42:49.420 --> 01:42:51.920
schön irgendwie so gebaut,

01:42:52.060 --> 01:42:54.240
dass es halt alles von dem

01:42:54.240 --> 01:42:57.460
Finger, der irgendwo draufklickt, bis zu

01:42:57.460 --> 01:42:59.200
dem Datenmodell halt alles

01:42:59.200 --> 01:43:01.120
schön ineinander greift und funktioniert.

01:43:01.900 --> 01:43:03.260
Das ist im Web leider alles nicht

01:43:03.260 --> 01:43:05.340
so wirklich und das fällt einem dann halt auch

01:43:05.340 --> 01:43:07.360
öfter auf oder auf den Fuß, weil

01:43:07.360 --> 01:43:09.120
man halt ganz so viele unterschiedliche

01:43:09.120 --> 01:43:12.060
Sprachen

01:43:12.060 --> 01:43:15.400
Layer hat, die irgendwie

01:43:15.400 --> 01:43:17.120
miteinander interagieren müssen. Jetzt der

01:43:17.120 --> 01:43:18.860
Django-Teil ist ja sozusagen nur der

01:43:18.860 --> 01:43:21.080
Teil der Web-Applikation,

01:43:21.260 --> 01:43:23.040
die sich jetzt auf einem Applikations-Server

01:43:23.040 --> 01:43:25.320
befindet und da irgendwie, und der Datenbankteil

01:43:25.320 --> 01:43:26.860
ist halt jetzt auch noch irgendwie mit drin, sozusagen.

01:43:27.660 --> 01:43:28.820
Aber, oder

01:43:28.820 --> 01:43:31.180
es rennt halt auch HTML nach vorne raus, aber es ist halt

01:43:31.180 --> 01:43:33.040
auch das HTML, also die Templates selber,

01:43:33.160 --> 01:43:35.140
ist das jetzt, ist HTML ein Teil von

01:43:35.140 --> 01:43:36.380
Django? Eigentlich eher nicht.

01:43:37.360 --> 01:43:39.300
Das ist eigentlich nochmal eine etwas andere Welt.

01:43:39.580 --> 01:43:41.320
Wie sieht das hinterher aus?

01:43:41.700 --> 01:43:43.160
Dazu braucht man dann CSS, das ist

01:43:43.160 --> 01:43:45.100
zwar auch irgendwie in Django drin, man kann halt,

01:43:45.200 --> 01:43:47.120
es gibt da, man kann SAS oder LESS

01:43:47.120 --> 01:43:49.200
oder was auch immer man verwenden möchte, um halt

01:43:49.200 --> 01:43:51.000
irgendwie das CSS von der Seite zu erzeugen,

01:43:51.060 --> 01:43:53.120
das kann man natürlich machen, aber wie man das

01:43:53.120 --> 01:43:54.960
jetzt macht und der Umgang damit, das ist natürlich wieder

01:43:54.960 --> 01:43:56.780
irgendwie so eine eigene Geschichte.

01:43:58.080 --> 01:43:59.100
Das ganze JavaScript,

01:43:59.440 --> 01:44:01.040
also der Teil der Web-Applikation, die halt auf dem

01:44:01.040 --> 01:44:03.000
Browser läuft, ist nochmal eine andere Geschichte, die wird dann

01:44:03.000 --> 01:44:05.060
halt auch vielleicht, die wird wahrscheinlich nicht

01:44:05.060 --> 01:44:06.820
mal von Django ausgeliefert, sondern von dem statischen

01:44:06.820 --> 01:44:08.900
Web-Server, der halt irgendwie vor Django meistens

01:44:08.900 --> 01:44:10.240
noch davor ist und irgendwie so

01:44:10.240 --> 01:44:12.540
Reverse-Proxy vor der Applikation ist,

01:44:12.720 --> 01:44:14.220
für statische Inhalte und Dinge.

01:44:16.600 --> 01:44:16.860
Und

01:44:16.860 --> 01:44:18.280
ja,

01:44:19.220 --> 01:44:20.820
Typografie,

01:44:21.060 --> 01:44:22.640
überhaupt wie

01:44:22.640 --> 01:44:25.540
SSL, dann die ganzen

01:44:25.540 --> 01:44:27.620
Netz, also da ist noch so viel Zeugs mit

01:44:27.620 --> 01:44:29.640
dabei, der halt auch eine Rolle spielt,

01:44:29.700 --> 01:44:30.780
wenn man jetzt so eine Webseite betreibt,

01:44:32.040 --> 01:44:33.540
der jetzt nicht unbedingt

01:44:33.540 --> 01:44:35.520
Teil von Django ist, da gibt es noch

01:44:35.520 --> 01:44:37.460
viel zu tun und das ist natürlich so ein Ding,

01:44:37.740 --> 01:44:39.220
also wenn man jetzt einfach nur Django

01:44:39.220 --> 01:44:41.400
macht, dann hat man damit die

01:44:41.400 --> 01:44:43.440
Komplexität dieses Gesamtdings

01:44:43.440 --> 01:44:45.000
irgendwie eine Webseite betreiben

01:44:45.000 --> 01:44:47.440
noch nicht komplett abgedeckt.

01:44:47.800 --> 01:44:49.320
Also es ist ein ganz guter Teil davon, aber

01:44:49.320 --> 01:44:51.080
da gibt es halt...

01:44:51.080 --> 01:44:53.180
Machen wir dazu tatsächlich nochmal eine Folge, also wie man eine Webseite

01:44:53.180 --> 01:44:55.220
komplett betreibt, so von Server und

01:44:55.220 --> 01:44:57.460
Deployment und wie man so, weiß ich nicht,

01:44:57.480 --> 01:44:59.680
Load Balance macht oder sowas.

01:44:59.820 --> 01:45:01.540
Könnte man auf jeden Fall auch. Hat dann nicht mehr

01:45:01.540 --> 01:45:03.100
so wahnsinnig viel mit Python zu tun.

01:45:03.780 --> 01:45:04.760
Unter Umständen... Gibt es das nicht in Python?

01:45:05.320 --> 01:45:07.420
Doch, man kann das auch alles in Python machen, aber ich mache

01:45:07.420 --> 01:45:07.900
das auch in Python.

01:45:10.460 --> 01:45:11.460
Nee, viele Bereiche

01:45:11.460 --> 01:45:13.460
gehen ja dann raus, auch aus der

01:45:13.460 --> 01:45:15.060
eigentlichen Programmierung und gehen dann in die

01:45:15.060 --> 01:45:17.300
Administration rein und da ist Python natürlich

01:45:17.300 --> 01:45:19.100
ein wichtiges Werkzeug, aber

01:45:19.100 --> 01:45:21.780
jetzt nicht das, worauf es läuft.

01:45:25.160 --> 01:45:27.520
Ja, also dann

01:45:27.520 --> 01:45:28.980
vielen Dank euch beiden hier, dass ihr

01:45:28.980 --> 01:45:31.400
so schön euch unterhalten habt,

01:45:31.460 --> 01:45:33.580
mir ein paar Fragen beantwortet habt, die ich so hatte.

01:45:34.780 --> 01:45:35.660
Ich glaube, so viel zusammenfassen

01:45:35.660 --> 01:45:37.520
müssen wir gar nicht. Wir haben so ein bisschen Dango gemacht heute.

01:45:39.020 --> 01:45:39.680
Ja, das war

01:45:39.680 --> 01:45:41.520
super und wir haben

01:45:41.520 --> 01:45:43.520
heute noch gar nicht über Events gesprochen, aber ich kenne gerade

01:45:43.520 --> 01:45:45.500
keine, die jetzt in nächster Zeit

01:45:45.500 --> 01:45:46.840
sind, so jetzt am Jahresende.

01:45:47.500 --> 01:45:49.500
Ich weiß nicht, ob euch welche

01:45:49.500 --> 01:45:51.460
einfallen? 12. Dezember

01:45:51.460 --> 01:45:53.540
ist Treffen der

01:45:53.540 --> 01:45:55.500
Python User Group

01:45:55.500 --> 01:45:56.340
Köln, PyCologne.

01:45:58.360 --> 01:45:59.320
Ja, jede Woche ist halt

01:45:59.320 --> 01:46:01.280
irgendwie Python-Fu in Düsseldorf.

01:46:01.820 --> 01:46:03.280
Nächstes PyTDF-Treffen ist erst

01:46:03.280 --> 01:46:05.020
wieder am 9. Januar, glaube ich. Also

01:46:05.020 --> 01:46:07.700
Treffen der Düsseldorfer Python User Group.

01:46:08.180 --> 01:46:09.200
Falls ihr eure eigene E-Mail

01:46:09.200 --> 01:46:11.000
promoten wollt, schreibt uns bitte bitte eine E-Mail.

01:46:11.160 --> 01:46:13.200
Ja, natürlich. Also ich meine, wir kennen

01:46:13.200 --> 01:46:15.440
jetzt nur die Sachen im Rheinland,

01:46:15.600 --> 01:46:16.740
Düsseldorf, Köln-Umfeld.

01:46:17.500 --> 01:46:20.220
Ja, würde ich sagen.

01:46:20.740 --> 01:46:21.880
Vielen Dank, schön, dass ihr zugehört habt.

01:46:22.520 --> 01:46:24.000
Noch einen schönen Tag, Morgen, Abend,

01:46:24.160 --> 01:46:25.420
wo auch immer ihr gerade seid, was ihr macht.

01:46:26.540 --> 01:46:27.460
Und ja, bis zum nächsten Mal.

01:46:27.460 --> 01:46:29.620
Bis zum nächsten Mal. Tschüss.