Transcript: Deployment von Webapplikationen

Ja, hallo liebe Hörerinnen und Hörer. Hier sind wir wieder, diesmal bei der zwölften Episode vom Python-Podcast.

Was machen wir heute? Heute machen wir ein bisschen Deployment für Anfänger.

Also so ein bisschen werde ich den Lochen löchern damit, wie man einfache Dinge auf irgendwelche Server bekommt.

Ja, ich bin der Dominik. Hallo. Jochen ist wieder da. Wir sind im Wintergarten.

Sommergarten ist wieder viel zu heiß.

Wir hoffen, euch geht es gut. Hört uns gerne zu. Schreibt uns gerne alles, was ihr wollt, alles, was ihr möchtet, an hallo.pythonpodcast.de.

Ja, schöne Grüße.

Ja, genau. Es haben auch tatsächlich Leute inzwischen so ein bisschen angefangen, die Kommentarfunktion zu benutzen.

Da war ich ja irgendwie...

Ja, unser Pocket-Cast-Chapter-Marsch funktioniert nicht so wirklich. Wir wollen irgendwann nochmal ein bisschen daran basteln, dass das dann mal geht.

Ja, unter den Kommentaren müssen wir wahrscheinlich auch noch so ein bisschen was tun.

Wäre es vielleicht nicht so schlecht, wenn man E-Mail-Benachrichtigungen kriegen könnte oder vielleicht zumindest ein Kommentar-Feed oder sowas.

Muss ich mal gucken. Geht bestimmt. Habe ich mir schon mal auf die To-Do-Liste geschrieben.

Aber es ist nicht nur sehr warm, es ist auch irgendwie sehr wenig Zeit momentan für alle möglichen Dinge.

Ja, ja. Alles auf einmal.

So ist das halt. Ja. Aber genau. So ein bisschen haben wir ja schon.

Insofern brauchen wir uns nicht die ganze Zeit nur zu beschweren, sondern können auch ein bisschen was erzählen.

Ja, diesmal röchere ich dich ja ganz viel mit lustigen Dingen.

Wie man, wieso man, warum man den ganzen Unsinn überhaupt macht.

Ja, ja. Ich finde, das ist ein interessantes Thema.

Und naja, das ist ehrlich gesagt, ich meine, so Inspirationen aus anderen Podcasts, die ich so höre, zu nehmen, ist momentan auch so ziemlich das Einzige, wo ich Inspirationen hernehmen kann.

Daher dachte ich, nehme ich mal irgendwie die Veröffentlichung von Jungle for Professionals von Will Vincent, die jetzt gerade irgendwie dieses Wochenende passiert ist, zum Anlass, da auch so ein bisschen was zuzusagen.

Weil ich hatte so ein bisschen, ich habe es noch nicht komplett durchgelesen, aber ich habe so ein bisschen reingeschaut.

Also, wie ihr merkt, wir sind direkt bei der nächsten Chapter-Mark-Szene.

Ja, Moment, genau, Moment.

News. Ja, alles klar, habe ich gesetzt.

Ja, so beim Durchblättern habe ich schon gedacht, okay, das sind genau die Sachen, mit denen ich auch schon irgendwie lange rumgeplagt habe.

Und das ist wirklich sehr schön gemacht.

Und ja, das ist eine Menge Zeug.

Also, wie betreibt man eigentlich überhaupt irgendwie so eine Webseite da draußen?

Und was macht man da alles?

Und gerade jetzt speziell irgendwie, was Jungle angeht, was muss man da alles tun?

Und insofern, wenn einen das interessiert oder man das Problem irgendwie hat, dann kann ich dieses Buch auch durchaus empfehlen.

Das ist eine sehr schöne Zusammenfassung von all den Dingen, die man da so beachten sollte.

Ja, aber eben, genau.

Also, ich fand immer, das kam immer zu kurz.

Also, auch wenn man sich so andere Bücher anguckt.

Dieser Teil, da wird dann immer gesagt so, naja.

Ja, äh, äh, äh.

Ähm, Hände wedeln.

Das ist alles kompliziert.

Das ist nicht so einfach.

Fragt einfach euer Ops-Team.

Ja, und dann hat man das vielleicht gar nicht.

Das ist blöd.

Ähm, ja.

Und, ähm, genau.

Das, äh, da kriegt man einen ganz guten Eindruck, was man da so tun kann.

Und irgendwie, ja, ich fand immer, das ist ein Thema, was zu kurz kommt, aber was halt durchaus sehr wichtig ist, damit man irgendwas auf die Straße kriegt.

Und darüber wollten wir so ein bisschen was reden.

Vor allen Dingen, weil, ja, wir müssen ja einfach mal alle Synergien nutzen, die wir kriegen können.

Ich glaube, du wolltest ja auch irgendwie so eine Webseite haben oder so, ne?

Ja, ja, genau.

Ich wollte so einen Server mal selber auch irgendwie aufsetzen.

Und, ähm, da brauche ich so ein bisschen Hilfe natürlich bei.

Und gucken, was man mit Python alles machen kann.

Und da löchere ich dich gleich ein bisschen mit.

Ja.

Ähm, haben wir noch irgendwelche News aus der Szene, die wir vielleicht dann noch hier reinbekommen?

Oder?

Ja, ich würde einfach mal die Sachen, die so, äh, passiert sind, einfach, äh, nach und nach.

Was haben, was haben wir denn da noch so, äh, äh.

Du hast noch so einen Postkast gehört am Wochenende.

Data Engineering.

Ähm.

Da hast du irgendwas Spannendes zu erzählen.

Da, ja, aber das weiß ich gar nicht, ob das jetzt so super in diese, dieses Format passt.

Da ging es um, äh, eine Firma, die halt so, äh, ja, Label, Data Labeling macht.

Also gut, ich mache ja auch viel Machine Learning Zeugs, äh, Data Science.

Und, ähm, da, also, ich fand, ich fand das deswegen gut.

Also, äh, weil, also, ich glaube, äh, wie hieß, ähm, wie hieß die Firma nochmal?

Cloudworker oder so.

Und der, äh, Chef von dem, äh, Gründer, hat da halt, äh, irgendwie auf dem Data Engineering Podcast da, äh,

äh, äh, was zu erzählt.

Und, ähm, äh, das, was er so beschrieben hat an, das sind die Probleme, die man normalerweise kriegt,

wenn man, äh, irgendwie, äh, Firmen dabei helfen will, äh, irgendwas in die Richtung zu machen.

Das kam mir schon alles sehr bekannt vor, weil das sind halt auch die Dinge, die, äh, ich immer beobachte,

wenn ich da irgendwelche Projekte zu mache.

Und, ähm, ja, das sind halt so, äh, eben.

Wenn man, die meisten denken, das ist kein Problem.

Woher kriegt man eigentlich die Daten?

Dabei ist das ein Riesenproblem.

Also, äh, das ist oft etwas, was nicht wirklich,

äh, gelöst wird, äh, oder wo viel größere Schwierigkeiten dann tatsächlich, äh, lauern.

Also, man soll was machen.

Die Leute kennen jetzt nicht alle Machine Learning, aber die haben gar keine Daten, um das zu tun.

Genau, oder denken, sie haben die Daten, kommen aber irgendwie nicht ran.

Oder brauchen die Daten aber in einem anderen Format.

Und dann gibt's irgendwelche Abteilungen, die sich da querstellen.

Das ist immer furchtbar.

Also, das ist immer ganz schrecklich.

An die Daten ranzukommen, ist meistens ein großes Problem.

Und, ähm, der war, der hatte auch so ein paar lustige Beispiele dafür, äh, wie momentan da, äh,

also, auch wenn ich, äh, kuriose Ideen der Leute kommen, um Daten zu bekommen.

Also, momentan ist es zum Beispiel, also, wenn man irgendwas mit Bilderkennung machen möchte oder so,

braucht man halt auch oft viele, viele Daten.

Und, äh, in, in Las Vegas scheint es wohl mittlerweile üblich zu sein, dass da, äh, wie die, äh, äh, wie, äh.

Hotelzimmer werden gefilmt.

Ja, ja, Hotelzimmer, oder man mietet auf Airbnb, äh, wie diverse, diverse Geschichten und bezahlt mehr oder weniger,

oder gibt Leuten Goodies dafür, dass sie sich da reinstellen.

Dann darf man Fotos von ihnen machen oder so, weil man ja irgendwie unterschiedliche Leute in unterschiedlichen Situationen haben muss, ne.

Nicht, dass, äh, irgendwie das Modell dann nur lernt.

Irgendwie den gleichen Raum wieder zu erkennen, das ist ja ja doof, deswegen braucht man unterschiedliche.

Und es ist, es ist nicht so einfach.

Und dann, äh, ist das natürlich auch relativ schnell, relativ teuer, wenn man die Daten versucht selber zu generieren.

Oder man muss irgendwie mit Drohnen rumfliegen und Sachen fotografieren und so.

Klingt ja nach großem Spaß.

Äh, ja, es, es klingt nach großem Spaß, aber es ist auch so ein bisschen, das ist alles so wilder Westen momentan so ein bisschen.

Was ja auch, ja.

Hooray!

Das wäre durchaus Spaß.

Ja, ja, genau.

Ja.

Brown Coat Night.

Ja, ähm.

Äh.

Genau, genau, das habe ich gehört, das fand ich, das fand ich ganz cool.

Ähm, kann man sich mal anhören, ich werde das, einfach den Link dazu in die Show Notes packen.

Das hat jetzt aber gar nicht so viel mit Python zu tun, sondern es war eher so, ja, wie kriege ich das eigentlich hin, wenn ich viele Daten zu annotieren habe und zu labeln.

Äh, eher so Data Science Machine Learning Geschichten.

Dann hat dir erst gleich was getwittert, ähm, zum nächsten Chat, glaube ich, war das.

Äh, ja.

Ah, äh, okay.

Äh, genau, da ging es um, ähm.

Fix.

Äh, pre, äh.

Pre-Talks, glaube ich.

Ja.

Ja.

Meine ich.

Ja, okay.

Das war der nächste Eintrag.

Ah, nein, doch.

Doch, ja, doch, genau, das ist es.

Äh, und zwar ist das so ein, äh, Kon, Konferenz, ähm, ja, Organisations, äh, äh, Organisationssoftware, die halt, äh, irgendwie viele Leute verwenden, ist auch so eigentlich ganz cool Django-basiert, ähm, äh, das, die wurde auch verwendet, um, äh, zum Beispiel die Subscribe, diese Podcast-Konferenz, äh, zu.

Ah, ja, da waren wir ja auch, ja.

Auch waren, ja.

Deswegen kam mir das schon so bekannt vor.

Es wurde auch damit, äh, äh, organisiert und viele, äh, ja, Events im CCC-Umfeld, vor allen Dingen wohl auch das Camp, wird halt damit, ähm, damit geplant.

Und, ähm, denen fehlt irgendwie, äh, ähm, ordentliches Ticketsystem.

Ähm, und irgendwie, dass auch Pre-Talks irgendwie mit E-Mails ordentlich umgehen kann und so.

Und deswegen hat auch Twitter mal gefragt, ob es da nicht Leute gibt, die sehr Lust hätten, sich mit, äh, zu beschäftigen oder vielleicht im Rahmen von einem Sprint auf dem Camp, äh.

Irgendwie da was dran zu tun.

Gerne auch, äh, Einsteiger, ne, weil man kann da sicherlich auch viel lernen und, äh, auch für andere ist es vielleicht mal eine Gelegenheit, Leuten was zu zeigen, wie Django da so funktioniert, was man da so tun kann.

Also fand ich auf jeden Fall eine, äh, gute Idee und, ähm, das Ding wollte ich mir auch immer schon mal näher angucken.

Äh, und, äh, ja, finde ich eine gute Gelegenheit.

Äh, ich würde da auch hingehen, wenn ich auf dem Camp wäre.

Ich weiß es aber nicht.

Ich fürchte, ich werde nicht da sein.

Ganz vielleicht doch, aber eher wahrscheinlich nicht.

Daher, äh, wird das leider nicht funktionieren.

Wann ist das denn überhaupt vielleicht für irgendjemand geneigt?

Äh, das Camp ist irgendwie Ende August, also.

Ich glaube, es ist alles ausverkauft worden, schon lange jetzt.

Ja, ja, schon lange, genau.

Ähm, äh, Moment, ich gucke mal gerade, das, äh, CC-Camp, wann ist denn das?

Also irgendwie, äh, 20. bis 25.8., ja.

Irgendwo in der Nähe von Berlin.

Genau.

Ja, ähm, also, äh, ist auf jeden Fall.

Wenn da zufällig jemand hingeht oder so, dann ist das.

Das ist sicher eine gute Gelegenheit, um sich mal intensiver mit Django, äh, beschäftigen zu können.

Und auch was Sinnvolles damit zu tun, was ja auch nicht so, dafür gibt es ja auch gar nicht so wahnsinnig viele Gelegenheiten oft.

Ähm, ja.

Und, ach, da hat eine Überleitung, äh, die da vielleicht auch, äh, direkt Sinn macht, ist, ähm, äh, habe ich auch gehört in einem Podcast.

Äh, ja, ich bin momentan viel auf Spielplätzen unterwegs und höre da Podcasten.

Ja, ja, ja.

Kinder toben.

Ja, ja, ja.

Vor allem dann langweilig, wenn man in der Sonne rumsteht.

Ähm, äh, und zwar ging es da um, äh, Tiger.io.

Äh, halt nicht so wie das, äh, wie das gefährlich raubt hier, sondern mehr so wie, äh, diese, äh, öde, äh, äh, weite Ödnis im Norden.

Das Projektmenschmentool.

Ja, das wollen wir doch später besprechen.

Nee, aber das passt jetzt super, das, äh, äh, hier ran zu, äh, äh, pflanschen, weil das ist nämlich, könnte man super auch mit dem P-Talks, äh, eigentlich verbinden.

Weil, äh, naja, da fehlt halt vielleicht so ein bisschen Ticketsystem.

Und das Tiger hat das auch schon eingebaut.

Und das hat irgendwie ein ziemlich cooles Ticketsystem eigentlich.

Und das ist halt auch Django und das ist vor allen Dingen ein Django REST-Framework, äh, und hat eine super API.

Das heißt, man kann das alles, äh, äh, toll auch, äh, irgendwie ansteuern ohne.

Jetzt müssen wir nochmal kurz erklären, was denn Tiger jetzt überhaupt ist.

Also Tiger ist ein Projektmenschmentool, wo man Boards bauen kann, Kanbans bauen kann.

So ein bisschen wie Trello, wenn ihr das vielleicht kennt oder so.

Wobei, ich würde sagen, also wenn, wenn man, äh, irgendwie, äh, Jira, äh, äh, herzliches Beileid.

Wer das kennt, aber, äh, ich hab, war öfter mal, äh, in der, also das Missvergnügen, irgendwie da, mich mit, äh, beschäftigen zu müssen.

Und das war immer, ist da immer meistens eher Schmerz.

Das kann aber auch sein, dass es einfach, ich meine, es ist einfach viel Zeug.

Und ich hab jetzt auch meistens nicht so viel Lust, mich wie ordentlich mit Projektmanagement-Software zu beschäftigen.

Daher, vielleicht lag's auch einfach daran, dass ich da nie so wirklich durchschaut hab, wie das funktioniert.

Und, äh, dann schnell was machen wollte.

Und das ging dann halt nicht, weil's kompliziert ist.

Und dann war ich irgendwie frustriert.

Mag sein.

Äh, vielleicht ist es auch einfach ein furchtbares Tool.

Kann sein.

Ähm.

Aber, ähm.

Also ich konnt's auch nie leiden.

Ja, auf der, das haben wir so auf der komplexen Enterprise-Seite irgendwie, ähm, möglicherweise.

Und dann irgendwie sowas wie Trello.

Ja, und also die Mutterfirma von, äh, Jira ist, äh, Atlassian.

Die auch mal so, ähm, na, wie hieß das, Bitbucket gemacht haben und so.

Die sich jetzt aber eher so in die Projektmanagement-Software-Ecke begeben haben.

Was wahrscheinlich ein schlauer Schlagzug war.

Und, ähm, auf der anderen Seite Trello.

Genau, äh, das eigentlich von den Leuten, die auch Stack Overflow gemacht haben.

Irgendwie mal gegründet worden, aber verkauft worden an, äh, an Atlassian.

Äh, aber das ist eher so eine leichtgewichtige Geschichte.

Und gefällt mir, der Ansatz gefällt mir irgendwie besser.

Aber auch wie man das bedient gefällt mir besser.

Kann natürlich nicht so viel wie, wie Jira.

Und, äh, das sind sozusagen vielleicht die beiden Pole, äh, die, äh, äh, so von super komplex Enterprise bis zu, äh, naja, relativ einfach und, äh, schlank und leicht zu bedienen.

Äh, auf der anderen Seite, äh, dazwischen gibt es aber von Atlassian jetzt nix.

Ähm, und, äh, da ist, glaub ich, oder da positioniert sich Taiga selber als, äh, ist ein bisschen, hat ein bisschen mehr Features als, als Trello.

Aber ist nicht ganz so, äh, nicht ganz so kompliziert wie jetzt, äh, wie jetzt Jira.

Aber, und es hat halt als, als Kernfeature halt ne, ne, ne API, sodass man quasi alles, man kann sogar mit der API mehr machen, als man jetzt mit dem Frontend machen könnte.

Daher, ähm, ja, es gibt, es gibt irgendwie mobile Apps irgendwie, die man da verwenden kann, die jemand anders gebaut hat.

Aber der gesehen hat, dass man die API verwenden kann, und dann hat er das einfach mal gebaut.

Ja, also wir werden auch, äh, später noch erzählen, wie man sowas denn auf dem Server hostet.

Das ist ja das, was wir damit tun.

Genau.

Wenn man das installieren wollte, es ist auch, es ist komplett, äh, freies Software.

Das heißt, man kann das irgendwie lokal sich installieren und da betreiben.

Das ist ja auch für viele Leute wahrscheinlich ganz wichtig, dass man das tun kann.

Und man kann halt auch reingucken und, und schauen, wie die da so Sachen implementiert haben.

Ich hab's ein bisschen reingeguckt und war, top, das ist eigentlich jetzt gut.

Ja, man kann seinen eigenen Board bauen, seinen eigenen Trello-Board organisieren, kann man Boards auf seinem eigenen Server basteln.

Und sowas hab ich auf jeden Fall vor.

Ich bin schon ziemlich gespannt, wie das alles funktioniert.

Ja, äh, genau, genau.

Also, Scrum macht das Ding, oder man macht halt, kann halt auch, äh, irgendwie kann man damit machen.

Äh, ja, und, ja, kann man sich ja mal anschauen, ist eigentlich ganz nett.

Ähm, äh, genau.

Ja, was hatten wir noch?

Ja, wir wollten eigentlich noch ganz kurz auf die Frage von Arnim eingehen, der uns eine E-Mail geschickt hatte.

Oh, das haben wir auch verschludert irgendwie.

Ja, das war ein bisschen her tatsächlich, schon, ähm, Mai, glaub ich.

Ähm, und, äh, ja, er wollte, äh,

mehr über Error-Driven-Development hören.

Und, ähm, ja, wir wollten eigentlich mal eine Folge zu Tests...

Ja, das machen wir auf jeden Fall.

...mal machen.

Ähm, aber das wird noch ein bisschen dauern.

Ja.

Und deswegen so viel, ja, äh, was meinst du denn überhaupt damit, Arnim?

Also, vielleicht nochmal irgendwie fragen.

Es gibt irgendwie da nicht so ganz klar, welche Methode...

Ich dachte, ich wüsste, was das, was gemeint wäre, aber dann hab ich nochmal gegoogelt und dann dachte ich so, oh nee, ich weiß doch nicht.

Weil, äh, also, ich glaub, das kam als Reaktion auf einen Pick aus einer Folge von Anfang Mai, wo wir erwähnt hatten, dass es MatMat oder, äh, gibt.

Und das Ding, ähm, macht, äh, äh, sozusagen guckt halt, ob...

Es war mehr so eine Geschichte, um zu schauen, ob deine Tests halbwegs abdecken, was dein Code so tut, indem es einfach deinen Code, äh, zufällig verändert.

Und dann guckt, ob die Tests brechen oder nicht.

Und wenn, äh, dein Code zufällig verändert werden kann, ohne dass deine Tests brechen, dann weißt du halt, mh, okay, ja, ist ein Problem.

Und, ähm, ja, sie nennen das Mutation Testing.

Äh, äh, das ist eigentlich, eigentlich auch eine ganz nette Idee.

Aber das würde ich jetzt Error-Driven...

Error-Driven-Development, weiß ich nicht.

Also, ich hab dann noch, also, äh, Leute benutzen den Begriff gerne als, äh, sozusagen Gegenbegriff zu Test-Driven-Development.

Ja, sozusagen, also, beziehungsweise, äh, schreiben dann halt, dass, wenn du kein Test-Driven-Development machst, dann machst du halt Error-Driven-Development.

Was, äh, vielleicht, wenn man sich das mal klar macht, also, natürlich ist das irgendwie schon so.

Und, äh, wenn man sich das mal klar macht, dann, dann kann man sich auch vielleicht vorstellen, dass es nicht so eine super schlaue Idee ist.

Sondern, dass man das vielleicht, äh, ja, dann gleich richtig machen kann.

Wobei, naja, ich mein, ich würd auch dieses...

Das Test-Driven-Development-Cool-Aid nicht, äh, irgendwie, äh, nicht einfach so schlucken, sondern da, äh...

Also, man, man sollte Sachen vielleicht nicht so total übertreiben, äh, was die, was die Reinheit angeht, der Gedanken.

Ähm, ich, ich probier auch oft lieber Dinge erstmal aus oder so, bevor ich dann Tests schreibe.

Weil man, ja, man legt sich halt auch, was die Implementation angeht, ziemlich fest, wenn man Tests schreibt.

Ähm, damit sollte man sich dann schon halbwegs sicher sein, was das Ding eigentlich machen soll, bevor man das tut.

Aber, ja.

Es ist auf jeden Fall, Testschreiben ist eine gute Idee und, ähm, äh, äh, sozusagen, ähm, sich nicht von den Fehlern, die User anreporten, äh, die quasi die Tests, äh, äh, äh, als Tests zu benutzen, ist wahrscheinlich eine ganz, ganz schlaue Idee.

Äh, aber wie gesagt, ich weiß nicht genau, was gemeint war.

Insofern nochmal nachfragen.

Ja, ja.

Wir machen auf jeden Fall noch eine, eine Folge zu, zu Testing.

Äh, wir müssen uns nur noch jemanden finden, der, äh, irgendwie Lust hat, da mit uns drüber zu reden und so.

Test ist nämlich immer das spannendste Thema von allen.

Ja.

Ja, ähm.

Was noch mal.

Ähm, es ist ja auch schon fast ein Monat her jetzt.

Wir haben ja schon, äh, Juli.

Ja, ja.

Ähm, es gab eine Folge über Visual Studio Code und da auch über Tests.

Da kam ich gerade drauf, glaube ich, ähm, die man mit Visual Studio Code machen kann und, ähm, das Debugging-System, äh, auf TalkPython2Me.

Ja, ja, ja.

Das, das war irgendwie der, glaube ich, der, der Produkt, Chef von den Produkt-Onern für Visual Studio Code irgendwie, der da interviewt wurde.

Oder der hat eine Menge auch interessante Sachen, äh, erzählt.

Ja, vor allen Dingen, dass Visual Studio Code halt auch irgendwie bei Python-Entwicklern so, äh, super populär ist.

Irgendwie, was sie, womit sie gar nicht so gerechnet hätten am Anfang, aber das hat sich irgendwie so rausgestellt.

Offenbar gab es da irgendwie so eine Marktlücke.

Ja, äh, ich benutze ja jetzt auch schon eine Zeit lang Visual Studio Code.

Äh, äh.

Ja, ich kannte das noch.

Ich, äh, hab, hast mich angesteckt.

Ja.

Ja.

War eine gute Idee.

Äh, ist tatsächlich auch ein Editorialisier.

Ich meine, es ist so eine, viele Leute mögen ja dieses Elektronen, dieser, ist auch ein elektronenbasierter Editorial insofern.

Ja, viele mögen das nicht so, aber es funktioniert ziemlich.

Also, wenn ich das zum Beispiel vergleiche mit PyCharm.

PyCharm verwende ich, habe ich auch irgendwie eine Zeit lang verwendet.

Oder fand ich auch ab und zu immer noch, aber, äh, tatsächlich fühlt sich das irgendwie deutlich, äh.

Softer an, ne?

So smoother.

Ja, irgendwie, äh, snappier.

Ich weiß nicht, was kam da noch vor?

Ja, es gibt da so ein paar Sachen, die funktionieren direkt, also irgendwie, ne?

Es ist einfach viel schneller.

Es fühlt sich schneller an.

Vielleicht ist es gar nicht schneller, aber es fühlt sich schneller an.

Die Sachen reagieren einfach viel.

Also die Latenz, wenn man auf irgendwas drückt oder so, oder irgendeine Tastenkombination angibt,

die Latenz, bis dann was passiert, ist deutlich schneller.

Vielleicht hast du ja noch ein Rechner gekauft inzwischen.

Ne, ne.

Ne, äh, das, daran, daran liegt es nicht.

Und, ähm, ja, das ist halt, äh, also, ja, weiß nicht, wie sie das, äh, ich weiß auch nicht,

vielleicht macht auch PyCharm irgendwas falsch, keine Ahnung.

Ja, das ist eigentlich cool.

Also irgendwie, wenn man seinen Code damit verwalten will, irgendwie auf Git oder sonst irgendwo,

das funktioniert super.

Integration mit Azure ist toll.

Man kann direkt automatisch CI, irgendwie CD machen und das alles pushen.

Man kann Live-Sharing machen und dann gemeinsam am Code arbeiten, was auch ziemlich gut funktioniert.

Ja, mit mehreren Cursor.

Und Link und Multicursor und Übertragung.

Ja.

Im Terminal und mittlerweile, also in einem Nightly-Build war das doch nicht top.

Das müsste mittlerweile sowieso schon im Stellbild sein,

dass man jetzt auch über SSA einfach sich irgendwo auf eine Maschine legen kann

und da im Verzeichnis entwickeln kann.

Das ist auch ziemlich praktisch.

Kannst du auch auf deine WSL-Maschine gehen oder auf den Raspberry

oder auf eine andere Server, wenn du lustig bist, und direkt da editieren.

Das ist ja auch oft ein Argument, was man hört, dass Leute sagen,

ja, ich nutze halt VI oder Vim, weil da habe ich überall die gleiche Entwicklungsumgebung.

Und, äh, ja, auch wenn ich mich auf irgendwelchen Produktionsmaschinen einlogge,

kann ich da auch mal...

Ähm, äh, meine Umgebung, so wie ich sie...

Aber, genau, ist natürlich in gewisser Weise ein Argument,

aber geht mit VS Code jetzt auch.

Da braucht man gar nicht mehr unbedingt Vim für verwenden.

Ja, ja.

Also, falls noch jemand rausbekommen hat, wie man sowas wie FoxDot verwendet mit VS Code,

das habe ich nämlich noch nicht hinbekommen,

also das ist Live-Evaluation von Python-Code,

da hätte ich noch Lust drauf.

Das würde ich gerne noch rausfinden.

Das müsste irgendwie funktionieren.

Dass man irgendwie, weiß nicht, Alt-Enter drückt oder sowas,

und dann spielt er direkt die eine Zeile,

dann kann man Musik machen mit FoxDot verpeisen.

Das fände ich noch super.

Sonst muss ich es nämlich...

Sonst muss ich es nämlich irgendwie dran basteln,

aber, ja, so viel...

Ja.

Und wenig Zeit für so viele Projekte, ja.

Du hattest irgendwas noch reingeschrieben,

PySimple...

PySimple GUI.

Ja, da gibt es jetzt irgendwie noch einigermaßen fünffige Versionen,

die ist jetzt auch irgendwie vor,

weiß nicht, wann das rausgekommen ist,

vor ein, zwei Wochen oder so,

die man ganz gut nutzen kann.

Das ist ein Wrapper für Tkinter, TK,

oder PyQ5.

Kann man beides benutzen mit derselben Syntax.

Man kann halt einfach angeben, welches der dann visualisieren soll

und...

Hat einen relativ einfachen GUI für die...

Ja, PySimple ist ja nicht so besonders stark

bei Nachverstandsprogrammierung

und das kann man damit aber ganz gut

und vor allen Dingen schnell und effektiv erledigen.

Das lohnt sich vielleicht da auch mal kurz rauszuschauen.

Wollen wir mal angucken.

Genau, jetzt hast du mir meine Woche schon fast geklaut.

Ach so, sorry.

Ja, ja, der kommt jetzt wieder.

Ja.

Oh, ein Podcast,

den ich auch noch gerne erwähnen würde,

ist auch einer der letzten Django-Chat-Folgen,

mit Simon Willison.

Also einer der Leute, die auch Django

quasi so mit aus der Taufe gehoben haben.

Ziemlich...

Ist alles so mit...

Audioqualität ist manchmal so ein bisschen...

Aber ansonsten inhaltlich

fand ich das sehr, sehr gut.

Das war sehr, sehr spannend, was er da so alles erzählt hat.

Also was die Geschichte von Django angeht,

aber auch, was so die aktuellen Entwicklungen

sind, was er für spannend hält.

Und das halt gerade irgendwie...

Ja, so momentan spielt...

Async-Geschichten spielen da eine große Rolle.

Die sind gerade sehr spannend.

Oder sein Privat...

Oder sein Pet-Projekt,

was aber jetzt auch mittlerweile so groß geworden ist,

dass...

Pet oder Pet?

Ja, ja, so ein Nebenprojekt halt.

Aber es ist nicht mehr wirklich so neben...

Das Peißen-Halsband für die Katze, oder?

Nee, ja, also...

Er hat da irgendwie

irgendeine Fellowship gekriegt,

ich weiß es nicht genau, wo er dann von irgendeiner

Uni ein Jahr lang bezahlt wird dafür, das jetzt zu entwickeln.

Das ist schon mal...

Daher geht auch die Entwicklung da momentan relativ schnell voran.

Das Projekt heißt Dataset.

Ach so.

Genau, das ist mir auch früher schon mal aufgefallen.

Hätte ich bestimmt auch schon mal ein paar Mal erwähnt, oder so.

Da hast du schon mal drüber gestolpert, ja.

Ja, genau. Darüber können wir bestimmt

auch nochmal eine eigene Sendung machen.

Ich wollte mich damit auch noch intensiver

beschäftigen. Das ist eigentlich eine sehr coole

Idee, irgendwie, wie man

mit einer

SQLite-Datenbank halt

Datensätze irgendwie

verfügbar machen kann, öffentlich,

ohne... Und zwar auf eine Art,

wie man halt sehr, sehr gut das abfragen kann, aber ohne...

Also man kann ja SQL-Statements einfach verwenden,

und man kann auch so coole Sachen machen, wie

JavaScript benutzen, um SQL-Statements

zu erzeugen, die man da verwenden kann, um die Daten noch zu fragen.

Voll gut. Und normalerweise

ist das alles puri bär, weil

schrecklich, schrecklich SQL-Injection droht und so,

aber man kann

SQL

SQLite so starten,

dass man sagt, irgendwie, ja,

das ist dann Datenbank-Street-Only,

und dann ist das alles nicht mehr schlimm, weil es kann nichts passieren.

Und

da ist das, was man normalerweise nicht tun sollte, dann plötzlich

alles erlaubt und cool.

Das ist

einfach, es ist nett.

Es hat viele überraschende Wendungen,

dieses Ding, wo man sich denkt, ach, cool, das geht,

das kann man so machen.

Die Datasette-Folge müssen wir uns ja nochmal aufschreiben, die steht nämlich gar nicht noch.

Ja, die muss da noch

mit drauf. Genau.

Also diese Podcast-Improvisation

kann ich Leuten durchaus, die sich für Django und

so interessieren, uns herzlichen, ist ja

sehr nett.

Ja, ich würde sagen, jetzt haben wir aber die News halt durch und machen

den nächsten Chapter, Marc, weil solange

löchere ich dich jetzt damit, wie das denn jetzt überhaupt funktioniert

mit dem Server. Und wir fangen wirklich von ganz

Basis-Bodensatz an,

also so gar keine Ahnung, wie macht ihr das und so

und wo und, ja, ich möchte nämlich

auch wissen, wie man das am besten macht, so Best Practice,

was sagt denn Jochen dazu?

Und, ja, ich würde sagen, können wir

starten jetzt mit unserem Hauptthema, ne, Server?

Dann starten wir da mal. Server, die Plattform für Anfänger, ja.

Erstmal Server,

was ist denn das? Also irgendwo

so ein Rechner, der irgendwie bedienbar ist,

das sollte ja irgendwie so klar sein, aber

ja, wen nehme ich denn da?

Also, was mache ich denn da für einen Server?

Nämlich irgendeinen Hosting-Anbieter,

Cloud-dedizierten Server,

virtuellen Server, warum und so?

Boah, ich brauche ja noch irgendwie

jetzt eine Domain und so, ne?

Wie würdest du denn das irgendwie so...

Ja, also was man auf jeden Fall tun

sollte, ist halt irgendwie eine Domain selber

registrieren und

was nicht so,

also,

man sollte vielleicht... Da schreibst du einen Brief und schickst den an eine Stelle.

Ja, ne, da gibt es ganz viele Anbieter.

Ich weiß nicht, kann man... Ich bin das Universum, ich hätte gerne diese

Domain. Ja.

Es gibt ja diverse Anbieter, da muss man halt

ein bisschen Geld bezahlen, das kostet gar nicht so viel pro Jahr

und dann hat man halt eine Domain.

Du hast gesagt, selber registrieren, also es gibt ja

verschiedenste Server, Poster, die

das alles mit einbieten. Ja, aber das ist

vielleicht nicht so eine schlaue Idee, das zu machen, sondern

besser... Aus welchem Grund?

Weil man das ja ändern können will. Also, bei vielen

kann man das auch ändern, das ist kein Problem, aber

also,

ich kenne das auch, dass viele, also so gerade,

weiß ich nicht, eben diese

ja,

Welt, Wald und Wiesen

da hat man dann oft irgendwie so ein

Formular, wo man irgendwie die NS-Geschichten eingeben

kann, aber dann halt die Sachen, die man

braucht, also weiß ich nicht,

irgendwelche, wie heißen

diese Dinger, Verified Domain

SPF Records oder

also es gibt diverse Records, die man unter Umständen

einstellen können möchte.

Was ist ein Record?

Oh Gott, oh Gott, oh Gott.

Wie ist das Domain Name System?

Also, das ist im Grunde eine verteilte

Datenbank, die

Informationen darüber

enthält, wie

Namen auf

IP-Adressen aufgelöst

werden und umgekehrt.

Das heißt, da steht irgendwo, wenn man irgendwie den

Nameserver irgendwie fragt, keine Ahnung, der einzige, der

wahrscheinlich bekannt ist, irgendwie der von Google mit den

4.8. oder sowas, oder 8.4.4

oder was, und dann gibt es ja auch noch einige unabhängigere,

wenn man nicht alle seine Daten zu Google schicken möchte.

Aber die fragt man dann und die wissen,

dann wo, hinter welcher IP oder hinter

welchem Namen, welcher IP steht.

Ja, man kann auch einen eigenen Resolver betreiben. Also man kann das

durchaus von Hand auch machen. Das ist vielleicht mal eine ganz interessante

Geschichte, dass man halt irgendwie

das mal einfach von Hand mit

den S-Abfragen

irgendwas resolft.

Man resolft das halt so von hinten nach vorne. Also wenn man

jetzt irgendwie

pythonpodcast.de hätte, dann würde man

erstmal gucken, okay, also was man wissen muss

ist, man braucht

irgendwie so einen Root-Nameserver, aber

wenn man eine IP von dem hat,

dann kann man den halt fragen, okay, was ist

in der Nameserver, der zuständig ist für die .de-Zone?

Der Root-Nameserver, das sind

die großen Knotenpunkte.

Kriege ich das irgendwie raus, wenn ich so einen Trace-Root

mache, wo die irgendwie hängen?

Ja, die sind weltweit verteilt. Da gibt es ein paar von

rootservers.net, irgendwie

a.rootservers.net oder ganz gerne ein paar.

Ich weiß jetzt gar nicht mehr genau,

alles schon altes Wissen, vielleicht ist es auch

mittlerweile alles anders, aber

auf der ganzen Welt sind da ein paar von denen verteilt

und

normalerweise

einige von denen sind halt

einfach, die IP-Adressen sind halt eingebaut in

diverse

Resolver-Libraries, daher

ja, aber das muss man irgendwie wissen, sonst kommt man halt

auch nicht weiter und von denen

kann man sich dann halt durchhangeln bis zu der

Domain, die man eigentlich haben möchte und quasi

für jeden Teil der Domain

fragt man dann halt den entsprechenden Nameserver,

also über

eben die Records, also NS-Records sind halt

die Records, die zuständig sind, einem

zu sagen, was denn der Nameserver

zuständig Nameserver ist, also ich frage halt quasi den

NS-Record

für .de, den Root-Server und dann

kriege ich halt irgendwie den Nameserver, der zuständig ist

für die .de-Zone

und das ist halt

na, wie heißen sie noch?

Hier

D-NIC,

irgendwo in Frankfurt stehen die, glaube ich

und

die haben dann das .de-Zone-File irgendwie

drin und da steht

dann halt drin, wer, also in dem File

steht vor allen Dingen, stehen die NS-Records

für alle .de-Domains,

also

wenn ich jetzt wissen will, wer ist,

welcher Nameserver ist dann zuständig für

pythonpodcast.de, dann hole ich mir

den NS-Record für pythonpodcast

in dem

Nameserver, der für .de

zuständig ist und dann

genau, kriege ich das irgendwie zu.

Und ich kann das auch irgendwie selber machen, dass ich

sage so, hey, hier, ich heiße jetzt gerne

Dominik

mein Python-Com oder sowas, oder

.de, wir wollen jetzt zu D-NIC und dann sage ich

der D-NIC so, hey, hier, ich wäre jetzt gerne so,

ist das noch frei und schicke das dann

da?

Ja, das geht nicht

unbedingt so einfach. Das heißt, ich muss da

einen Registrier, Registrar

verwenden. Ja, also früher ging das auch,

da ist man da vorbeigegangen beim D-NIC,

hat da die Tür geklopft und gesagt, hallo,

ich hätte da mal so gerne ein Domain.

Aber das geht schon lange nicht mehr.

Ja, da kamen so viele

Leute wahrscheinlich auf diese Idee, ja.

Ja, das

geht schon lange nicht mehr.

Aber Gandhi macht das

dann zum Beispiel, wenn ich jetzt bei dem Domain...

Es gibt ganz viele unterschiedliche, also ich weiß gar nicht, ob es da

ich weiß nicht, ob das, was ich da verwende, gut ist

oder nicht, keine Ahnung. Es spielt auch

keine große Rolle, weil es ist, die können alle

irgendwie mehr oder weniger das Gleiche.

Ja, aber was wichtig

ist, dass man selber das registriert hat und selber

dann sozusagen die

Sachen ändern kann und halt auch das umziehen

kann, wenn man mag und so.

Und das ist halt bei diesen, wenn man das beim Provider macht,

oft ist es auch so, dass es geht,

aber manchmal halt auch nicht und dann hat man ein Problem,

wenn man zum Beispiel den Hoster wechseln möchte.

Ja.

Und ja, genau.

Aber

ja, das ist so das Erste, was man braucht.

Einen eigenen Domain braucht man noch für viele andere Dinge.

Wenn man Indie-Web machen will, braucht man auch einen eigenen Domain.

Jetzt brauchen wir irgendwie so einen Computer, der irgendwie so läuft.

Also die Frage ist, muss der schnell sein, muss der langsam sein?

Was ist das denn? Also haben wir da tatsächlich

einen eigenen Computer, der mit

Kernfestweise...

Ich war mit dem Auflösen noch nicht fertig.

Also wenn man jetzt den NS-Rekord von

einem Domain hat, das heißt noch nicht, dann muss man den

Names aber noch fragen, was ist denn jetzt zum Beispiel der

A-Rekord? Das ist halt das, was halt die IP einem

gibt für

eine bestimmte

Domain.

Es gibt dann auch andere. Es gibt MX-Rekords,

die halt einem sagen, wo die...

wer zuständig ist für Mail.

Es gibt halt...

Ja, es gibt ja eine ganze Menge Zeugs.

Es gibt doch Text-Rekords und

weißer Teufel. Und manche von denen werden auch

missbraucht, um andere Sachen zu signalisieren. Aber wenn man

solche Sachen machen möchte, wie...

und man möchte Mail

irgendwie von einem

Drittanbieter machen lassen, weil man keinen Bock hat,

das irgendwie alles selber

aufzusetzen und zu maintainen, dann

muss man da eine ganze

Menge Records setzen und so.

Oder auch für andere Geschichten,

Services, die man da benutzen kann, damit halt sozusagen andere

unter

mehr oder weniger unter der Domain auftreten

können.

Das würde ich auf jeden Fall auch machen. Ich möchte ja gerne ganze

Projekte unter unterschiedlichen Domains, die ich mir

dann irgendwie buche, vielleicht auf einen größeren

Server legen und die dann irgendwie da reinrouten.

Ja, das ist immer ein anderes Problem,

das geht natürlich auch, aber allein

ist gut, DNS unter Kontrolle zu haben.

Jedenfalls, also man muss nicht

unbedingt einen eigenen Nameserver betreiben, das mache ich

teilweise noch, aber das ist auch irgendwie

eher schmerzhaft.

Weil man hat auch direkt so mit Security

Geschichten oft, dann gibt es

so diese komischen DNS Amplification

Angriffe und blöde

Geschichten und so Zeugs, mit denen man zu tun

kriegt.

Ja, aber

also

man will das eigentlich, glaube ich, nicht unbedingt

selber betreiben, wenn man da nicht Spaß dran hat.

Aber trotzdem möchte man

die Records bestimmen können, weil das

für viele Services, die man sonst so benutzen

möchte, halt auch wichtig ist.

Ich glaube, damit sind wir aber mit DNS im Grunde durch.

Ja, jetzt kommen wir endlich auf einen Server. Jetzt haben wir so einen Server, der hat

dann irgendwie nur so eine IP und dann

wissen wir noch gar nicht, dass wir nicht, aber...

Nee, noch nicht. Wir haben nur das DNS

unter Kontrolle. Wir können das jetzt auf eine beliebige IP zeigen

lassen, sozusagen.

Es gibt sogar so die DynDNS,

das heißt, wir könnten sogar zu Hause einfach einen Rechner ans Netz

hängen oder so.

Ja, aber dann musst du dann Games aber

selber betreiben, irgendwie, wahrscheinlich.

Ich glaube, es gibt so einen Service, da muss man immer nur

sagen, hey, ich bin jetzt hier, ich bin jetzt hier, ich bin jetzt hier.

Ja, ja, klar. Es gibt auch in vielen

Routern ist das eingebaut, zum Beispiel eine Fritzbox

macht das. Dem kann man einfach

sagen, so, das ist mein DynDNS-Anbieter

und dann

kriegt man halt immer eine entsprechende,

dann macht die das automatisch.

Wenn sich die IP-Adresse ändert, dann schickt die halt

irgendwie ein Request dahin und sagt, okay,

findest mich hier, hallo. Genau.

Und dann kann man auch sein Kram zu Hause

immer erreichen, ja.

Wobei man da wahrscheinlich eigentlich eher

sowas wie ein VPN verwenden will, aber

DynDNS geht auch. Aber ist eigentlich

heutzutage alles nicht mehr so richtig relevant, glaube ich.

Ja,

genau. Also wenn man DynDNS unter Kontrolle

hat, dann kann man halt jetzt, wenn man

jetzt einen Server hätte,

irgendwo, der unter der IP

verfügbar ist, dann

kann man sozusagen

die Domänen darauf zeigen lassen.

So, und jetzt ist die Frage, was für ein

Rechner will ich denn da haben? Will ich irgendwie vom großen

Rechenzentrum haben? Will ich einen bei mir zu Hause

in die Ecke stellen? Möchte ich irgendwie so

einen Cloud-Server mir mieten? Möchte ich so einen dedizierten

Server haben? Das kann man ja skalieren von

zwei bis, weiß nicht, wahrscheinlich 200, 2000

Euro im Monat. Ja, das kommt auch an.

Also, was man damit vorhat, für die

meisten Leute wird

irgendwie da weniger, wahrscheinlich eher

mehr sein. Also, es wird wenig reichen, weil

Ja, es gibt ja auch so

WordPress-Hosting-Anbieter oder sowas.

Da kann man wahrscheinlich nichts anderes machen, außer ein WordPress-

Blog drauf.

Der auch schon ziemlich viel kann, wenn man

jetzt nicht so viele Besucher hat.

Aber, ja, ist

aber nicht das, was man wahrscheinlich haben will, wenn man

jetzt Python macht oder so. Da möchte man das

schon selber tun

können. Also, es gibt auch eben

für Python-Hosting nicht

so viele Anbieter, die da

Was ist denn jetzt Python-Hosting?

Weil ich dachte, da läuft jetzt ein Computer.

Genau, ja. Das ist halt, also bei

WordPress ist halt klar, das ist halt die Software.

Sowas gibt es natürlich für bestimmte

Python-Geschichten

auch. Also, es gibt zum Beispiel, muss ich

jetzt nochmal nachgucken, habe ich letztens irgendwie gesehen, wenn man

jetzt einfach nur ein CMS haben will unter der

Domain, da gibt es da auch Anbieter.

Diego, Diego, Diego, ich weiß

es nicht mehr, muss ich mal nachgucken.

Die bieten an, dass man irgendwie ein

Wagtail-CMS oder halt

ein Django-CMS

bekommt, da

gehostet und das ist dann so ähnlich wie

WordPress-Hosting. Also, so. Okay, das läuft ja auch

im virtuellen Container irgendwo.

Nee, das, ja, das weiß ich

nicht, ob die da ein extra

Container pro

Seite hochfahren. Ich denke

nicht. Also, wenn man sich zum Beispiel, also,

wenn man sich anguckt,

was da die User sind, die man teilweise, wenn man in manchen

Feldern versucht, irgendwas einzugeben, dann kommt da eine

Liste der User hoch oder so. Da kommt

ziemlich wildes Zeug hoch. Das heißt, ich gehe mal davon

aus, dass es nicht irgendwie pro

Domain oder so gekapselt, sondern das

ist halt eine Datenbank, auf der alle sind. Und dann gibt es halt

unterschiedliche Sites. Und

das ist ja auch durchaus vernünftig unter Umständen.

Also, du brauchst

nicht unbedingt einen Container für

eine eigene Seite. Da ist es

gar nicht nötig. Ist ja bei

WordPress-Geschichten wahrscheinlich auch nicht so.

Und

genau, das

gibt durchaus da auch Anbieter, aber das sind viel weniger

als jetzt im PHP-Umfeld oder WordPress oder so,

wo es eine große Geschichte ist.

Was eher

eine Rolle spielt,

wenn man jetzt Python-Applikationen irgendwo hosten

will, ist halt sowas wie, also wenn man jetzt

kommerzielle Anbieter, wir gehen einfach mal von

einfach zu, es wird schwieriger oder komplizierter.

Oder man kann mehr selber kontrollieren

durch, wenn man

so, sie heißen alle so Platform-as-a-Service-Anbieter

sich anguckt.

Also ganz oben wäre sowas wie eben,

du kriegst halt irgendwie

dein Backtail-CMS und hast dann halt

ein fertiges CMS unter deiner Domain.

Das wäre halt sozusagen alles

Am besten noch mit Admin-Interface

und unten. Genau, das wäre dann auch irgendwie so quasi,

ich weiß gar nicht, ob das das wäre, das wäre wahrscheinlich Software-as-a-Service

mehr oder weniger Modell. Dann

Platform-as-a-Service ist, naja, du

ähm

ähm

sagst nicht, du kriegst jetzt nicht eine fertige

Webseite sozusagen, schlüsselfertig

äh, sondern

du kannst eine fertige Webseite, ja,

sondern du kriegst halt irgendwie

äh, du hast halt einen Account bei Heroku

oder sowas, also Anbieter wären das sowas wie Heroku

oder Python Anywhere oder so.

Und ähm, da

äh

Ich vergleiche mich mit diesen Häusern unheimlich toll.

Mit den Hochhaus-Hinz-Stellen und Gartenhütte, ne?

Ja, also sag mal so,

das ist halt, äh

äh, im Grunde

ja, da, da sind das dann oft wahrscheinlich

Container, die da hochgefahren werden, äh, und

du hast halt solche Dinge wie Datenbank, ist halt

schon einfach irgendwie mal nicht da. Du wohnst in einem Hotel.

Du musst wohnen, dann gehst du unten in die Lobby.

Es ist quasi so eine Art Hotel, ja.

Ich weiß nicht, ob diese Analogie trägt, also

wenn, wenn Software-as-a-Service, also wenn

die, wenn diese... Ich war konziersch, ich hätte gerne einen

Kaffee. Ja,

was wäre denn dann, was wäre denn das fertige,

die fertige, das fertige WordPress, dass man

sich nur noch einloggen braucht?

Da ist der Pool schon vorgeheizt und

äh,

äh,

ich würde sagen, das ist doch eigentlich eher das Hotel, oder?

Wo man halt sich um nichts kümmern muss und das...

Und Heroku ist die Ferienwohnung, wo du selber kochst.

Ja, und Heroku ist so ein bisschen die,

es ist eher so, äh,

nicht mal das, es ist eher so

der, äh,

die, die, die Schuhkarton-

Eigentumswohnung irgendwo, das ist halt der Container

halt, oder es ist halt wie der Container auf dem Schiff, ja, wo man

irgendwie die ganze Inneneinrichtung

und so, das muss man halt selber machen, weil es ist halt nicht drin und

das kann man auch komplett austauschen, das ist natürlich auch irgendwie

ein Vorteil. Ja. Ähm,

da kannst du halt sagen, okay,

ich deploy da halt irgendwie

ein Flask, äh, ja,

Flask-Ding hin oder halt eben, äh,

ein Django, äh, hin oder so.

Ähm,

äh, aber du bist da halt nicht festgelegt, ja,

also auch nicht auf, äh, ja.

Und, ähm,

ja,

äh, äh, aber

diverse andere Geschichten werden dann schon abgenommen, ja,

also man kümmert sich sozusagen nur noch um

den Teil, der halt, wenn man alles selber machen würde,

äh, im Applikations-

Server, jetzt nenne ich das mal so, äh,

äh, laufen würde, äh,

um, um den Applikationsteil kümmert man sich, ja, aber

sowas wie Datenbank, das macht man nicht selbst, da gibt's dann halt

und es gibt auch endlos viele andere Plugins

und Dinge, die man dazuklicken kann, äh,

Suchmaschinen oder

irgendwelche, irgendwelche anderen, äh, Sachen, die man halt

auch verwenden kann und das muss man alles dann nicht selber machen

bei, bei Heroku jetzt beispielsweise, sondern das

ist halt dann einfach da. Ähm,

und man kümmert sich nur um die

Applikationen, die man dahin deployt und, äh,

natürlich definiert man irgendwie die Datenbank

dadurch, dass man jetzt in Django beispielsweise die ganzen

Modelle halt irgendwie, äh,

ja, definiert und, äh, die werden dann halt auch

in der, in der Postgres, äh, irgendwie

eingelegt, aber man betreibt die Postgres-Datenbank nicht

mehr selber, sondern das macht halt irgendwie, äh,

macht entweder Heroku oder einer von den Drittanbietern,

die halt ein Postgres-Plugin

für Heroku anbieten, für einen.

Was natürlich dazu führt, dass es

wesentlich weniger, äh,

aufwendig ist für einen Server.

Ähm, aber man ist halt auch so

ein bisschen eingeschränkt und, ähm,

diese Geschichten führen halt oft dazu,

also, äh, ich hab das tatsächlich mal

versucht, weil ich hab versucht für, äh,

äh, es ist ja auch sowas, ne, wenn man,

wenn man... Das klingt nicht nach einem gelungenen

Experiment. Ja, für Django, Django

Cast jetzt diese, wollte ich einfach mal so,

wie ist das denn, wenn man das jetzt auf Heroku mal deployen will,

zum Testen, damit man es halt draußen irgendwo, äh,

laufen hat, aber, äh,

ähm, ja,

man möchte jetzt nicht vielleicht irgendwie so ein Commitment,

äh, eingehen, da jeden Monat Geld zu bezahlen

oder so, das, oder hat halt dann auch keinen

Root-Server irgendwo rumstehen, den man benutzen könnte.

Darauf kommen wir irgendwie später wieder.

Ja, dann, dann wäre es doch ganz praktisch,

wenn man das einfach mal nach Heroku oder, oder so die

pläut und dann mal guckt, wie das so funktioniert.

Dachte ich, das wäre eigentlich ganz nett und zumal

halt all diese Anbieter alle so freie

Container anbieten, die also

für Hobby-Benutzung oder so,

die halt nichts kosten, äh, die dann auch

bestimmte Anforderungen nicht erfüllen,

beziehungsweise keine garantierte, äh, die sind beim ersten

Laden oft langsam, weil das ist wahrscheinlich

unten drunter irgendwie

Docker-Container oder vielleicht benutzen die dann irgendwie

Lambda-Funktionen

bei AWS oder so, wer weiß.

Ja, genau, das sagst du ja schon wieder.

Äh, nein, nein, ich bin mir noch mal auf...

Äh, äh, also

da kann es sein, dass der Container erst gestartet wird, wenn man,

wenn so ein Request reinkommt und dann ist das halt ein bisschen

langsam und doof und, äh, aber

es stört ja nicht, wenn man, äh,

wenn man das eh nur so

mal ausprobieren möchte, ne, und, ähm,

ja, äh,

und dann hab ich da, mich da gemacht,

da so ein bisschen eine Anleitung für zu schreiben und dann

ist mir relativ schnell aufgefallen, es ist,

ist es nicht so einfach, äh, und ich war

überrascht, wie, wie knifflig das ist und ich bin immer noch

ein bisschen überrascht, äh, dass auch Heroku

da, da keine gute Anleitung für hat, wie, wie macht

man das eigentlich, so machen die nicht nur Python, die machen auch

Ruby on Rails und, und, und auch

Node.js und weiß der Teufel, aber

trotzdem, es ist schon, äh, irgendwie, es war

schwerer, als ich dachte und ich dachte mir so, ui,

also, äh,

hm. Ja, wenn der Jungen daran knabbert, dann

weiß ich jetzt nicht, ob ich jetzt anfänge, unbedingt

mich da so reinstürzen

möchte. Also, ich meine, auch dieses Django for

Professionals Buch kann man sich auch mal angucken, auch der,

äh, obwohl Vincent meinte es schon so,

das ist alles irgendwie immer, also die Sachen so hinzukriegen,

dass sie dann tatsächlich funktionieren, so, ist oft

schwerer, als man so denkt und es war echt

nicht mal ganz einfach. Das Containerschiff ist vielleicht

überladen und hat irgendwie halbe Schlagzeit, man weiß es

nicht genau. Ja, also, aber es ist halt, also,

ich fand jetzt überraschend, wie viel wenig

einfacher das ist, als wenn man

alles selber macht. Also, der Schritt von,

also, ehrlich gesagt, ich find's, das mag

daran liegen, dass ich das häufiger selber

mache, äh, irgendwie, ich fand es einfacher,

das selber zu machen, als bei Heroku

und das, weil man stößt halt sofort

auf so Probleme, gut, kann auch sein, dass mir das,

vielleicht ist das vielen Leuten egal,

aber ich denk mir halt so, naja, heutzutage, Webseite

ohne SSL, das ist eigentlich eher kaputt. Also,

es muss eigentlich, SSL muss irgendwie gehen

und eigentlich ist das ja auch kein Problem mehr mit

Let's Encrypt und so, aber

für die Hobby-Seite

bei Heroku, bei

denen, ähm, funktioniert

das nicht und das hat mich, es hat mir,

es ist mir nicht leicht gefallen,

rauszukriegen, dass es wirklich nicht funktioniert

und ich musste da tief graben

und ich bin in irgendwelchen Issues gelandet, wo dann

einer von den Entwicklern bei Heroku dann irgendwie

schon, puh, sollten wir vielleicht mal in die Dokumentation

schreiben, dass das wirklich nicht geht. Also, auch mit

diesem Weg geht das nicht und, äh,

da dachte ich schon so, ja, solltet ihr vielleicht, weil

irgendwie, ich hab jetzt grad da irgendwie ganz schön

Zeit reingesteckt, das rauszukriegen,

also, weil es sah so aus, als würde es vielleicht doch funktionieren, wenn man

dann irgendwie die Zertifikat von Hand hochlädt oder so,

nee, tut's nicht. Und dann hab ich mir erst

da lokal irgendwie Z-Bot installiert

und da irgendwie auch rumgeeiert und, ja,

aber es ging dann alles am Schluss nicht.

Also, SSL hatte TPS,

Heroku nur, wenn man zahlt, sonst geht's nicht.

Und, ähm,

ja, äh, auch die, ähm,

wenn man jetzt irgendwie

ein CDN verwendet oder so,

äh, Content Delivery Network, ja, da müssen wir auch noch mal

rechnen. Ja, da kommt alles noch dazu.

Ist alles... Anfängerfreundliche

Folge, Jochen. Ja, ist alles nicht so

einfach. Auf jeden Fall, man, also, ich meine, man

kann sich das ja mal angucken, wenn man

jetzt auf HTTPS nicht so viel Wert liegt

oder, äh, dann kriegt man auch

mit Heroku wahrscheinlich schon halbwegs

schnell da irgendwie zum Ziel, ob

ein anderes Alternativ ist, gibt, glaub ich, noch

ein paar. Ähm,

und das kann man auf jeden Fall auch verwenden.

Also, man hat auf jeden Fall diesen ganzen

operativen Kram von der Backe, was natürlich auch schon

mal ein großer Vorteil ist. Also, man muss sich nicht dafür,

äh, also, man muss sich nicht,

äh, ähm, selber dafür interessieren,

wie das Zeug jetzt, äh, ob das oben ist

oder nicht. Also, das macht halt,

äh, jemand für einen und

das ist ja auch schon mal nicht so schlecht.

Ähm, ja,

äh, das wäre sozusagen eine

Zwischenschicht zwischen irgendwie

alles ist fertig und... Hört sich nicht so an, als würde ich

das machen wollen, ehrlich gesagt. Doch, also, ich kann mir

durchaus vorstellen, dass es gute Gründe gibt, das zu

machen. Äh... Nee, für mich nicht.

Ja.

Nach der Geduld, wo wir sind ausgeschlossen, ja.

Für dich jetzt nicht, aber, äh, ich denke schon,

dass es für mich, aber, oder es gibt, was

auch oft eine Falle ist, dann, wenn, wenn, wenn

Startups irgendwie anfangen mit sowas, dass sie dann

irgendwann doch viele Datenbank, äh,

äh, Queries machen und da sind auch, äh,

das, das ist, eine ganze Menge ist irgendwie frei.

Aber wenn man dann

aus diesem Bereich, wo das frei ist, irgendwie

rauskommt, dann wird es sehr, sehr schnell brutal

teuer. Und, äh,

das ist auch so etwas, was man vielleicht nicht, nicht unbedingt

haben will. Aber das Problem ist, wenn man dann gerade wächst

oder so, dann kann man nicht mehr so schnell

irgendwie... Und die Infrastruktur komplett umfassen.

Ja, ja, und dann gibt man halt ein...

Vermögen. Dann gibt man Arm und Bein an

diese Anbieter. Tja.

Was ja irgendwie so dein Geschäftsmodell ist.

Ist auch nicht verwerflich, finde ich. Ist okay, aber man sollte

sich halt bewusst sein, dass man da eventuell ein Problem bekommen kann.

Ähm,

ja, also das ist eine, eine Möglichkeit, die man halt

auch machen muss. Ja, jetzt müssen wir aber noch mal ganz

kurz, bevor wir das alles wieder vergessen haben, kurz eingehen

darauf. Quantitative Network, du musst auf dem

Geschirr auch schon noch mal kurz erklären. Und, äh, AWS

Lambda-Funktion. Ja, also, also wenn wir jetzt

bei, wir sind jetzt bei, also, so sagen

wir jetzt der Grund der Software-as-a-Service, Plattform-as-a-Service.

So, jetzt wären wir quasi das Nächste,

was nicht mehr, das, wo man ein bisschen mehr

Freiheit hat, aber, äh,

ähm, sozusagen immer noch,

äh, nicht so viel selber machen muss,

wäre dann Infrastructure-as-a-Service.

Also das wäre dann halt sowas wie,

ähm, ja,

Amazon EC2.

Ähm,

DigitalOcean.

Also da, äh, bekommt

man im Grunde, äh, ja,

einen Container, auf dem irgendein Linux

oder so läuft, wo man sich einloggen kann als, als

Root per SSH. Und dann

ist man auf sich alleine gestellt. Da muss man, man,

den Rest macht man dann halt selber. Ähm,

das hört sich gar nicht so schlecht an.

Ja, das hört sich gar nicht so schlecht an. Das ist auch, glaube ich, eine ganz,

äh, ganz nette

Geschichte. Welches Linux nimm ich denn da?

Fedora, Ubuntu, Debian?

Spielt im Grunde keine große Rolle,

würde ich jetzt mal so sagen. Also, äh,

äh, ich,

vielleicht. Gibt es kein System, das besonders gut Python

unterstützt oder so? Nee. Nee, das

System Python kann man in keinem von den Fällen verwenden.

Da, ja. Das ist egal.

Muss man eh immer neu installieren. Oder selber installieren.

Ähm.

Hat Fedora jetzt nicht drei standardmäßig alles schon

drin? Ja, trotzdem, nee.

Wie wäre das? Barry Warsaw hat

das mal auch auf Twitter geschrieben, so,

First rule of Python is you don't use system, don't use

system Python.

Du musst ja immer dein eigenes Python installieren.

Das ist kein Spaß. Ähm,

ja, also, äh,

genau, also insofern würde ich sagen,

also der einzige Unterschied, den ich noch sehen würde, der

relevant ist, ist einmal, welches Paket

Management System einem irgendwie besser oder

schlechter gefällt und, ähm,

ob man System D mag oder nicht.

Weil, äh, genau, wenn man das

mag, dann kann man das ja benutzen und da gibt's halt

Unterschiede, je nachdem, welche Distribution man verwendet.

Also System D, du brauchst dann sowas wie Logging

ab oder sowas, das mag man vielleicht nicht, oder?

Ja, aber auch vor allen Dingen sowas wie, wie, wie sorgt

man eigentlich dafür, dass der Kram, den man, äh,

laufen haben möchte, eigentlich läuft und

am Laufen bleibt und so. Das, ähm,

ja, äh, kann man über

System D auch machen. Ähm,

kann auch irgendwas anderes nehmen. Äh,

ich nehm öfter Super-Wise-D,

äh, aber es ist auch,

im Grunde ist das nicht alter.

Was war ja, äh, Init, äh, was, äh,

F, Init, System 5?

System 5, ich weiß nicht genau, Init-Files,

äh, es gibt da auch andere Konzepte,

wie man, ja, also System D hat schon

nette Konzepte, aber es ist halt auch,

es hat da so manchmal so...

Vielleicht hat da irgendwie eine ganz spannende, äh,

Folge dazu nochmal gehört, irgendwann, äh,

die fahren irgendeinem Chaos-Radio-Express

mit einem von den Developern da,

irgendwie, das war schon ein bisschen... Ja,

äh, na, wer ist da noch?

Äh, ja, Namensgerechtes,

keine Ahnung. Ja, genau.

Äh, ja.

Okay, also völlig egal, welches System, also ich hau mir dann

Fedora und Ubuntu drauf, zum Beispiel, weil ich

das so ein bisschen schon kenne oder so,

dann irgendwie, dann mit den Repos schon ein bisschen weiß,

wo ich meine Pakete finde und dann

ist der To oder warum sollte ich das tun?

Warum nicht direkt einen eigenen Server? Also...

Ja, genau, weil halt auch da dir das natürlich

abgenommen wird, dass du dafür sorgen musst,

äh, dass das Ding ordentlich läuft oder so.

Ähm,

du...

Ja, du musst dich um viele Dinge nicht kümmern,

die du sonst tun müsstest.

Ähm, und, ähm...

Ja, dieses ganze, also,

alles, was mit irgendwie Netzwerk zu tun hat...

Steckereien stecken, Strom... Genau, dass das Ding

immer oben bleibt, äh, irgendwie Betriebssystem-Updates,

weiß ich gar nicht, noch nicht stimmt, das muss man wahrscheinlich noch selber machen.

Ja, genau, ich meine, Managed Server, glaube ich,

heißt das oder sowas? Ja, das will man alles,

wahrscheinlich eher nicht, aber, äh, genau.

Ja,

aber man muss sich, also schon um

wesentliche Teile der Infrastruktur jetzt bei

so einer Geschichte nicht kümmern. Also, im Grunde ist

halt der Container wie der andere, und

das funktioniert einfach so, ne, und dann...

Also, das ist schon, das ist schon auch nett,

aber man zahlt natürlich auch einen Preis,

das ist halt schon teurer, als wenn man jetzt, äh...

Und dann, es gibt nochmal so superbillig, äh,

äh, superbillige, äh,

äh, Geschichten auch immer, also die,

ich glaube, die kleinsten Container,

wenn die durchlaufen sollen, die kosten dann irgendwie

ein paar

10 Euro im Monat oder sowas, ich weiß es nicht genau.

Äh, aber es gibt auch so

Dinge wie bei Amazon Light Sale, heißt das,

glaube ich, irgendwie, wo man dann für

wenige Euro im Monat so ein Ding,

einen Container kriegt, und bei, äh,

DigitalOcean gibt es das auch, also,

und selbst bei sowas wie, äh,

so ein Husabee-Hetzner, also kriegt man irgendwie

einen Container, der, der durchläuft,

ähm, für

2,50 Euro oder 3 Euro oder so wenig

Geld im Monat, und hat dann ein richtiges

Linux mit, wo man sich als Root einloggen

kann, ist schon natürlich ganz nett.

Und das will man wahrscheinlich sogar auch tun.

Ja, äh, hängt dann davon ab, dass man dann, wenn man

jetzt eine fette Datenbank braucht, dann geht das halt wahrscheinlich nicht mehr,

dann braucht man halt Hauptspeicher, und den hat man

leider nicht. Aber, äh,

ja, so, so eine feste Installation...

Aber wann braucht man denn eine fette Datenbank?

Also, so, jetzt als, äh, Datenmensch

muss ja wissen, ab wie viel Traffic man da so irgendwie...

Nee, das hat mit dem Traffic gar nicht so viel zu tun, sondern eher

viel damit zu tun, wie viel Daten es sind.

Weil du willst, dass dein, äh,

Working Set im Hauptspeicher ist. Und das heißt,

wenn du halt irgendwie ein paar Gigabyte, äh,

Daten hast, dann willst du halt ein paar Gigabyte

Hauptspeicher haben, mindestens mal. Ja, so oft wie zu viel.

Oder so. Also ungefähr doppelt so groß

wie mein Dataset sollte der Hauptspeicher dann sein.

Ja, also, später geht das dann irgendwann

nicht mehr, aber, äh, ja,

sollte schon da reinpassen.

Ähm,

und das, äh, die haben alle

wenig Hauptspeicher natürlich, weil die teilen sich, die sind halt

auf großen Maschinen meistens, aber es sind viele

kleine Container, und dann muss halt irgendwie,

wenn die alle vier Hauptspeicher verbrauchen, ist

halt natürlich irgendwie der Hauptspeicher weg.

Wie kompliziert wäre es denn jetzt da,

weiß nicht, wenn man jetzt mehrere kleine

Services auf so einem Ding laufen lässt,

einen von denen umzuziehen?

Auf eine größere Maschine.

Oh, das ist, ja, da

bist du dann schon, das ist alles nicht mehr so einfach.

Ich würde auch das nicht so machen,

dass ich die Sachen da direkt laufen lasse.

Kann man auch tun, aber

ich würde eher sowas wie Docker nehmen.

Tatsächlich.

Also das heißt, du würdest dann auf einem dieser

Cloud-Dinger einen Docker

bauen, installieren

oder... Docker installieren, Docker-Demon

starten und dann halt

mit so einem Docker-Compose-File

das komplette System hochziehen, sodass dann

halt für jeden Service, den man benutzen

möchte im System, das man

da hochfährt, dass man dafür einen Container

hat, also einen Container für die Datenbank,

man hat einen Container für Redis...

Und man teilt sich dann genau die Dinge auf, also kann man

Docker so einstellen, dass der für alle verschiedenen Systeme

unterschiedliche Hardware nimmt, weil...

Ja, das kannst du natürlich auch tun, aber das

würde ich am Anfang auch

nicht machen. Nee, und dann

geht es eher so in den Bereich von

Kubernetes und diesen Geschichten, das

willst du nicht, du willst das...

Also das ist auch gar kein Problem, also

das musst du nicht

machen, also... Also Kubernetes ist eine

Krake an Docker-Containern.

Ja, das ist so ein bisschen, das

Problem mit Docker ist halt, dass

das zu betreiben ist halt

fies, Netzwerk ist fies, das ist alles...

Das entwickelt sich auch alles noch, das ist

alles nicht so richtig

gefestigt, das ist nicht ganz so

schlimm wie jetzt

bei den JavaScript-Frontends

bei React oder so, aber

es ist schon, es ist nicht

so, also man kann sich da nicht so gut drauf verlassen

und vor allen Dingen fehlt die Unterstützung für viele Sachen,

und dann gibt es da eben dann,

wenn man das im Großen, wenn man

eine komplette Cloud irgendwo betreiben möchte

oder so, dann nimmt man da andere Geschichten,

Management-Geschichten für, da wäre

jetzt Kubernetes ein Beispiel für, aber

die Frage ist, ob man das braucht, und wenn du das selber

irgendwie nur ein System, das brauchst du nicht,

also würde ich jetzt mal anfangen,

würde ich jetzt einfach so sagen, brauchst du nicht.

Ja, also ich habe da bestimmte Voraussetzungen tatsächlich, also ich möchte so

verschiedene Webseiten betreiben,

irgendwie, ne, irgendwie private Sachen, dann

hatten wir mal über Indie-Web besprochen, dann

irgendwie sind die beiden Services da drauf, und dann vielleicht noch

irgendwie eine Firmen-Webseite mit einem kleinen Login

und vielleicht noch für IoT so ein bisschen

so ein Server, der da irgendwie läuft

und das irgendwie alles gerne parallel, und

ja, das ist ja kein Problem.

Wie baue ich das denn? Also wo fange ich denn da an?

Also ich habe jetzt so einen Server dann Cloud

am besten gemietet, oder vielleicht doch irgendwie

so einen dedizierten irgendwo hingestellt, oder

nur einen kleinen virtuellen genommen, oder?

Das hängt halt wieder davon ab, also ich würde einfach mal,

also nur um das halt auszuprobieren,

würde ich mit so einer kleinen Geschichte anfangen.

Ja, aber das ist meine Frage nach dem Umzug,

also wenn ich dann merke, so, oh, um

zu ziehen, irgendwie alles normal machen, also das ist ja

Nee, musst du nicht, das ist ja, dafür hast du ja

deine Domain registriert.

Ja, aber den Server muss ich ja umziehen, also die ganzen Sachen muss ich ja

nochmal konfigurieren. Ja, aber dann nee, dann

musst du gar nichts machen. Wenn du Docker nimmst,

hast du dieses Problem gelöst.

Achso, also ich baue den Container einfach

neu auf einem anderen System.

Ja, genau, sagst du einfach auf dem anderen System

docker-compose, dann docker-yaml-file,

ab, fertig.

Nicht mal das, also gut,

man würde das jetzt nicht von Hand ausführen, sondern

man würde dann halt irgendwie das System, die an

hängen oder in Supervice-D,

normalerweise die Konfiguration dafür

legst du auch in dein Projektverzeichnis mit rein,

linkst das

nur noch nach etc.supervice-d.conf

oder weiß ich, wo die

Config-Files dafür liegen, startest das Ding

einmal neu und dann startet der deinen kompletten

Kram, ohne dass du noch irgendwas machst. Also wie gesagt,

wenn ich auf dem Server das deploye,

da muss ich einen Link

ziehen, ich muss

etwas an der Caddy-Config

ändern, das machst du, dann startest du neu, fertig.

Caddy ist jetzt dieses,

also ich muss da irgendwas rein, ist die Reihenfolge

entscheidend, wie das da drin hängt, weil die dann nacheinander

gelaufen, wie verteilt der die

Ressourcen verteilt, also wie viele er hat.

Ja, also gut, das ist nochmal

ein anderes Thema.

Wir sind zu weit, wir sind zu weit.

Ja, also es ging nur

darum, wie kriegst du das Zeugs

irgendwie auf einer Maschine zum Laufen

und da

würde ich empfehlen, heutzutage Docker zu nehmen.

Man kann auch andere Sachen benutzen, aber

background. Ja, man könnte auch

background, aber das ist auch, es braucht auch

mehr Ressourcen, also das würde ich jetzt

zum Beispiel, wenn du irgendwie so in dem Container,

vor allen Dingen, Container ist ja, also es ist natürlich

auch irgendwie performantechnisch sehr fies, also

in einem Container nochmal Container-Geschichte

zu starten, ist vielleicht auch nicht so die

schlauste Idee performantechnisch, aber es ist halt

zum Entwickeln, es ist halt

so, würde ich sagen, state of the art

eigentlich, oder es ist halt

am wenigsten schmerzhaft, von allem,

was es so momentan gibt.

Vagrant kann man lokal ganz gut verwenden, oder

halt, wenn man einen dicken Server hat, aber

du kannst es nicht gut verwenden in einem

kleinen Container, weil

das braucht halt, das fährt halt wirklich

ein komplettes Linux hoch.

Und du kannst natürlich darin alles

wieder betreiben, du musst dann nicht das

in einzelne Container aufhalten, aber

ja, aber

das ist, wenn du wenig Hauptspeicher hast,

ist das vielleicht einfach keine gute Idee.

Na, und Docker

passt da eigentlich ganz gut zu, da hast du

dann zwar auch Container in Container, aber

es ist nicht so, du fährst

nicht jedes Mal ein komplettes Betriebssystem hoch und so,

eine komplette Maschine.

Ja,

du kannst

natürlich das auch irgendwie komplett einfach

in diesen Container, alle deine Services, die du

so haben willst, starten.

Du kannst halt zum Beispiel,

auch das benutzt man eher für größere

Infrastrukturen, um da halt

komplette Systeme auszurollen.

Das ist eigentlich so Automatisierung

deiner

Automatisierung deiner

Infrastruktur hochziehens,

so nennt man sowas wie Ansible oder so,

es gibt auch noch diverse andere, es gibt Solstack, es gibt

irgendwie

Puppet Chef,

aber Ansible wäre jetzt auch Python

und damit

verwaltest du quasi

ein ganzes Inventory an Rechnern

irgendwie und sagst dann, roll mein

System aus und dann, das Ding braucht auch nur SSH,

dann connectet es sich auf all die Systeme per SSH

und

macht dann magisch Dinge, sodass dann da die Services

laufen, die da laufen sollen und so.

Irgendwie sowas braucht man auch, wenn man

Vagrant verwenden wollte, weil du musst ja die Services dann irgendwie

in deinem Vagrant, in deiner virtuellen Maschine

halt auch zum Laufen kriegen, das heißt, du musst da irgendwie die

entsprechenden Pakete installieren, musst du die Services

hochfahren, musst die Config-Files irgendwie

mit Templates so

irgendwie, also hast du Templates

für deine Config-Files, dann musst du die so mit den echten IP-Adressen

und so ersetzen, dass dann die richtigen Config-Files

da sind, dann muss das Ganze hochgefahren werden

und so weiter und so weiter.

Und für so ein komplettes System irgendwie

Ansible rollen,

nennt man das zu schreiben, das geht alles, hab ich auch schon

gemacht und so,

aber das ist eine Menge Arbeit, also das ist nicht

so ohne und das dann auszurollen dauert

auch ziemlich lange.

Das ist halt auch so ein Nachteil

gegenüber Docker, also das ist halt

irgendwie so ein komplettes

Ding mit Vagrant hochzuziehen, kann sein, dass das

selbst wenn du einen schnellen Rechner hast, lokal, kann sein, dass

das 20 Minuten dauert, wenn du so viele

Maschinen hochfährst oder so. Kannst natürlich auch alles

in einer Maschine haben, aber dann hast du wieder das Problem, du kannst es nicht mehr

aufteilen, wenn du es jetzt

auf andere Maschinen aufteilen wolltest und so

und ach, ja, also

und das ist halt

einfach oft zu langsam, wenn jetzt

wenn du zum Beispiel irgendwas, du versuchst

irgendeine Funktion hinzukriegen, musst dafür irgendeine Bibliothek

installieren, die das halt kann

ein Python-Trepper drumherum, der da irgendwas mitmacht

und du willst halt so schnell

iterieren können, du willst halt schnell irgendwas ausprobieren

geht nicht, nochmal, so

und bei Docker dauert so ein Build

für, weiß ich jetzt

CPU-Power, je nachdem

CPU-Power und Platten und Netz man hat

aber so bei mir dauert das, ich hab

also Standard-Django-Projekt

hat bei mir irgendwie die Datenbank

Redis, irgendwie

Applikationszauber-Django, vielleicht noch

Celery oder so, also 5, 6 Container

irgendwie sowas, die alle

neu zu bauen, wenn man jetzt zum Beispiel

eine Abhängigkeit im Betriebssystem, also

sagen wir mal, jetzt irgendwie

auf Betriebssystem-Level irgendeine Bibliothek braucht oder so

die vorher nicht da war, dann muss man

die Docker-File, muss man die Container neu bauen

und das dauert bei mir so

ja

zwei bis drei Minuten, lokal

je nach Größe der Anwendung natürlich

je nach Größe der Anwendung, aber das ist

ja, die Anwendung

selber, die Django-Anwendung hat damit gar nichts mehr zu tun

der Hauptteil, der da dauert, ist

halt

tatsächlich die Installation

und das Bauen

der Container und dann halt hinterher müssen

nochmal die ganzen PIP-Abhängigkeiten

per PIP installiert werden, das dauert auch

ja, aber das ist halt

viel, viel schneller, als wenn man das

jetzt per Ansible und Vagrant machen wollte

und das

Problem ist halt, drei Minuten ist auch schon lang

aber das macht

einem so gerade vielleicht den Flow noch nicht

kaputt, aber wenn man jetzt irgendwie da, dann

jedes Mal 20 Minuten warten muss, dann geht man

Kaffee trinken und man macht da irgendwas anderes

und man muss aber möglicherweise 10 Mal

was anderes ausprobieren, weil

oft muss man, bleibt einem nichts übrig, als Sachen auszuprobieren

ob es jetzt so geht, ach scheiße

der Python-Wrapper funktioniert nicht, muss einen anderen nehmen

probier den nochmal aus

wenn du da 10 Mal irgendwas ausprobieren möchtest

und du hast immer eine

20 Minuten Latenz dazwischen ist, das

macht einen langsam

Du hast gerade gesagt, im Stack von dir gehört

noch eine Redis, das ist ein Cache, da hat man

irgendwie Sachen von der Datenbank direkt verfügbar

hat

Ja, einfach nur zum Cachen von beliebigen Dingen

nicht nur Datenbank, also es gibt ja auch

vielleicht andere Sachen, die länger laufen oder wo man halt

Statische Files oder sowas

Nee, nee, nee, das machen wir nicht

Nee, also es gibt noch

wenn du jetzt statische Files cachen möchtest

das würde man auf einer anderen Seite machen

also Redis ist etwas, die

also wenn ich jetzt zum Beispiel

in Django eine Funktion habe, die

irgendwas lange

berechnet oder so, dann ist fertig

dann schreibe ich darüber

irgendwie Cache-Property oder so

zum Beispiel in Django, um zu sagen

in Django zu sagen, cache das hier mal bitte, weil

ich will das nicht jedes Mal, wenn dieses

diese Property

jemand, wenn jemand

darauf zugreift, möchte ich nicht, dass es jedes Mal neu berechnet wird

oder es soll nur einmal berechnet werden

und dann im Cache landen. Und dann verwende ich diesen

Dekorator und dann landet

das im Redis. Also wenn ich jetzt Redis

konfiguriert habe, als das ist der Cache

für meine Django-Applikation.

Für sowas ist es gut. Man kann Redis auch noch

für diverse andere Geschichten verwenden.

Und

wenn ich jetzt sozusagen

die statischen Files cachen wollte

in Memory, das kann auch durchaus Sinn machen, aber das

würde ich an einer anderen Stelle machen. Und zwar

vorne dran, vor dem Django.

Vor dem Applikationsfang.

Da würde ich

den Varnish nehmen oder so. Das ist so ein

In-Memory-Cache,

den man

davor hängt. Und

der würde halt

sozusagen alles, was an statischen Files geht,

die da durchgehen, halt

In-Memory-Cachen.

Oder überhaupt alles, was an statischen Assets drin ist.

Oder auf andere Sachen auch.

Überhaupt alle

Dinge, die identifizierbar

sind als cachebar über die Cache-Header.

Und das wäre

dann viel, viel schneller.

Macht man dann an der Stelle.

Ist jetzt aber in meinen Projekten meistens gar nicht mit drin,

weil

brauche ich eigentlich meistens nicht,

weil ich habe nicht so viel Traffic. Wenn ich jetzt irgendwo

viel Traffic hätte, ja, dann macht das

wahrscheinlich durchaus Sinn, sowas zu verwenden.

Aber

ansonsten werden die statischen Assets

halt ausgeliefert entweder von

in meinem Fall meistens

vom Caddy.

Das ist der

Stack nochmal komplett durch.

Also das, was davor ist. Und das ist auch etwas, was leider

nicht in dem

Docker-Geschichten selber mit, also

sagen wir mal so, wenn man jetzt Cookie-Cutter

verwendet, um ein Django-Projekt

zu erzeugen, dann ist der Caddy schon

mit drin. Aber man

kann das oft nicht verwenden, wenn

man das jetzt auf irgendeine Maschine da draußen

deployt oder in einen Container,

auf den man sich per Route einloggt.

Weil, wenn man da jetzt zum Beispiel mehrere Domains

hat,

die man

da ausliefern will,

dann muss der Caddy

halt unabhängig von den

einzelnen Systemen sein, sonst geht das halt nicht.

Und was macht der Caddy denn jetzt?

Und wie hat er noch, im Celery hattest du noch eventuell,

ich muss da auch nochmal kurz.

Ja, also Caddy ist ein grob geschriebener

Web-Server,

der

besonders schön integriert ist mit

halt Let's Encrypt, sodass halt HTTPS,

also SLL, TLS kann

halt ohne, dass man da irgendwie viel konfigurieren muss,

ohne dass man irgendwie Startboard selber

irgendwie verändern muss.

Und also

es ist so,

ja, HTTPS funktioniert einfach magisch

und man muss sich nicht mehr kümmern.

Das ist also der Effekt,

was ja ganz nett ist.

Und

der ist auch sonst relativ schnell, der ist nicht ganz so schnell

wie Nginx oder so, aber

ich meine, ob das Ding jetzt, weiß ich nicht, 10.000

Requests pro Sekunde kann oder nur 5.000,

macht für die allermeisten Leute überhaupt keinen Unterschied, weil

sie haben nicht mal ein Request pro Sekunde,

ja, ist egal.

2, 3, 4, ja.

Ja, aber selbst bei 100 ist es völlig wurscht.

Und, ähm, ja,

und das ist dann gut geschrieben, vielleicht ist das Ganze auch noch ein bisschen

vertrauenswürdiger als, wenn ich meine Nginx

C und so, hm, wer weiß.

Ähm, aber,

naja, eigentlich ist es wurscht. Also was für mich

den Ausschlag gibt, den zu verwenden, ist halt

die schöne Let's Encrypt-Integration.

Und, ähm,

ja, der ist sozusagen vor den,

vor Django davor, halt eben um sowas

wie Statisch-Falz ausliefern, weil das kann halt Django

nicht so gut selber. Wobei, muss man auch einschränken

und sagen, äh,

mit White Noise ist das vielleicht nicht mehr so gut,

ganz, äh, aktuell, ähm, aber,

äh, was ist White Noise?

Oh Gott.

Das ist, äh, ein,

hm, ja, äh,

äh, ich weiß nicht,

das gibt es nur für Django, es ist, auf jeden Fall,

innerhalb von Django kann man das als, kann man das, äh,

als, äh, Party-App installieren.

Und das liefert dann Files,

also, wenn man normalerweise einfach so

einen File ausliefern würde in Django, dann

zieht man das halt in den Hauptspeicher, also,

ja, von der Platte in den Hauptspeicher und dann

von dem Hauptspeicher schickt man es wieder durch,

äh, äh, durch den

Kernel-Space irgendwie da raus über die

Netzwerkkarte und

da wird viel, viele Daten werden da kopiert

und, äh, das ist alles scheußlich und man blockiert

einen, ähm,

Worker-Prozess.

Hängt auch viel davon ab, welche, welchen Applikations-

Server verwendet, Junicorn,

Micro-Whiskey oder My-Whiskey

oder WSGI oder so, also,

das ist alles der gleiche, ich weiß nur nicht, wer ausgesprochen wird.

Ähm, äh,

man muss ja irgendeinen, irgendeinen

Applikations-Server verwenden, der sozusagen die

WSGI-Protokoll spricht,

äh, ähm, mit der Applikation

und, ähm,

naja,

äh, also, wenn man, wenn man, wenn man

das File tatsächlich einfach so selbst ausliefert,

äh, dann ist das extrem

langsam und dann ist halt bei wenigen Files

ist dann halt schon direkt Schluss.

Äh, und das ist natürlich etwas, was man,

was man nicht haben will, äh, und

wenn man, wenn der, der Caddy,

äh, oder auch, äh, ein Nginx

kann halt, äh, problemlos viele

Files, äh, irgendwie, äh, ausliefern,

äh, und macht das halt nicht so,

dass er erst die Files in den Hauptspeicher kopiert,

dann durch den User, äh, also vom

Kernel zu den User-Files und dann wieder zurück schiebt,

um das auszuliefern, sondern der

verwendet halt einen, einen Kernel, äh,

ähm, einen syscall, äh,

send-File, um die Files halt raus zu,

äh, sagt halt diesem Kernel

nur irgendwie hier, dieses File, äh,

diese Verbindung bitte sehr, liefer aus.

Sodass das halt, äh,

ja, viel, viel schneller ist, also

der Kernel liefert im Grunde mehr oder weniger die Files aus.

Mhm.

Äh, und, äh, kann ja irgendwelche

Tricks machen, teilweise werden die Sachen

nicht mehr durch den Hauptspeicher, äh, sondern gehen

direkt per Serial-Copy-TCP irgendwie

in den Netzwerkwaffer der Karte

oder so von den Platten aus und so, also

gibt's, äh, crazy, äh,

Shit-Optimierungskrams, der da

gemacht wird, bin ich jetzt auch nicht mehr so auf der Höhe

der Zeit, was halt momentan aktuell ist, aber es geht irgendwie

eine Menge, und

White Noise macht das, macht auch, verwendet

auch send-File, insofern ist das da nicht mehr so schlimm.

Ähm, aber,

äh, eigentlich will

man jetzt auch nicht große Mengen darüber ausliefern,

weil der, der Request ja dann immer noch aufschlägt

im, im Django, ähm,

oder jeder, der Request nach einem File,

und das kann halt viel sein, ja, also wenn man viele kleine Bilder

hat auf einer Webseite zum Beispiel,

wenn man eine Liste mit, mit, äh, von irgendwelchen Dingen,

wo halt immer Bilder dabei sind, dann

ist halt jedes Bild, macht halt ein Request.

Und, ähm, im modernen

Browser machen die ganzen Requests ja auch ein Parallel,

das heißt, die prügeln halt dann auf deine

Applikations-Server ein, und das ist halt, äh,

das ist, äh, nicht so gut.

Und, äh,

ähm, da,

äh, äh,

was, was, ich mach's nicht so,

aber, was wohl gut ist, ist halt, man

verwendet White Noise, und dann da vorne

irgendwie Varnish oder sowas, oder halt

ein CDN, sodass halt beim ersten Mal

werden die Sachen dann tatsächlich von White Noise ausgeliefert,

und danach sind sie halt gecached irgendwo in

Content-Delivery-Network oder halt Varnish

oder so, und dann ist es schnell.

Ähm, was ich mache,

ich, äh, ich verwende

meistens den, den

Webserver eben Caddy oder Nginx vorne dran zum

Aufwählen meiner statischen Assets,

da gibt's halt einen Unterschied in Django,

also statische Geschichten, das ist sowas wie JavaScript,

CSS,

äh, Faf-Icon,

dieser ganze Kram halt sozusagen, der

äh, ja,

zum Projekt halt dazugehört, aber jetzt

sich im Grunde nicht ändert, also das,

das Firmen-Logo, was du immer schon eingebaut hast.

Ja, genau, also wenn man, die, die Sachen werden

dann auch generiert, diese High-Namen, äh,

und dann, sobald man,

äh, da was dran

ändert und dann noch Collect-Static aufruft,

um das halt alles in einen Verzeichnis zu kopieren, das dann halt

von einem Webserver ausgeliefert werden kann, dann kriegen die halt,

äh, unike Namen, sodass das halt, man auch

sagen kann, die werden für immer gecached, weil, wenn es

was Neues gibt, dann wird der eh einen anderen Namen verwendet.

Ja, ähm,

das ist halt, dieses Headlink-Design-Static-Files

ist halt ein bisschen anders, als wenn

jetzt User Bilder hochladen oder so, ne, dann ist

das, äh, Media-Root in Django und

es wird halt, also ein bisschen anders gehandelt und

statische Files sind bei mir, werden

ausgeliefert vom, vom, äh, Caddy

und, ähm, alles,

was User irgendwie an Content hochladen,

äh, landet in einem CDN, äh,

landet in, äh, S3.

In einem Bucket. In einem Bucket. Und

der wiederum wird dann ausgeliefert über,

äh, ich glaub, das ist CloudFront,

äh, das ist auch das, äh, CDN

von, von, von Amazon.

So, dass ich halt auch damit keinen

Stress mehr habe, äh, sondern das,

äh, ja, dann, äh,

das ist dann halt auch

schnell. Ist halt ein bisschen,

ja, muss man vielleicht gar nicht machen,

weiß ich jetzt gar nicht so genau, äh,

aber es ist halt auch eine Lösung.

Das ist natürlich auch eine, ja, genau, das ist dann auch

quasi beliebig. Ja.

Ähm,

ja, Traffic wird halt irgendwann teuer, da muss man

sich...

Ja, aber man muss halt dann

pro, äh, pro, ja, weiß ich nicht,

weiß ich gar nicht, pro Gigabyte oder, weiß ich nicht,

irgendwann bezahlt man halt pro irgendwas.

Man hat irgendwie 100 Gigabyte frei oder so, dann fängt man

irgendwann an zu bezahlen.

2 Euro pro Request.

Ist nicht ganz so schlimm, aber es ist, äh, hm.

Ja, und wenn man das selber macht mit, mit, mit

White Noise und so, kann man wirklicherweise sich da

auch den Traffic sparen, was auch schnell ist.

Ja. Gut, nee, wenn man CDN

drauf vorne ranfen will, auch nicht. Wie auch immer.

Also, genau, das...

Ja, das haben wir auf jeden Fall in den, in den Gango, äh, Applikations-

Server, da hast du gesagt, Gionicorn, irgendwas laufen.

Gionicorn, ja, also ich würde sagen, wenn man, äh, eben nicht,

äh, mehrere Seiten hostet,

äh, dann, äh, sondern

dass er so ein eigenes Projekt hat, was

irgendwie, und der Applikations-Server nur

das, äh, für eine Geschichte macht,

für einen Domain oder so, dann, dann ist

Gionicorn, denke ich, die bessere Wahl.

Ansonsten, wenn es komplizierter ist,

dann, gut, muss man vielleicht, äh,

dieses WSGI-Ding

nehmen, UWSGI.

Das hat, äh, einen Haufen,

äh, Einstellungen, die ja darauf

optimiert sind, dass man, äh, wenn man, äh, wenn man Hoster ist

selber, äh, und dann, ja,

kann man halt auch eine Menge andere Dinge noch einstellen.

Ist aber komplizierter, daher würde

ich das jetzt nicht, äh, nicht direkt empfehlen, auch wenn man

Cookiecutter nimmt, ist Gionicorn dabei.

Ich würde sowieso empfehlen, das Cookiecutter-Giango-Template

zu verwenden, weil das macht eigentlich an der Stelle schon

viel richtig, und, ähm,

ja, äh, da kriegt man

da kommt man da, da muss man sich selber um diese...

Also Cookiecutter ist was, was deine Projekte

automatisch vorkonfiguriert, deployed

oder, oder vorangestellt.

Nee, das erzeugt das Projekt, das erzeugt das Projekt, also es hat

halt, ähm, quasi, es ist ein Projekt-Template

und es fragt einen, wenn man

es ausführt, am Anfang, äh,

so ein paar Sachen, und da antwortet

man halt so, zum Beispiel, wie das Projekt heißt, oder

keine Ahnung, ob man jetzt Celery verwenden möchte oder

nicht, oder so, oder welche Daten man...

Celery hast du jetzt auch noch nicht gehabt, das ist dann wie

Arbeiten, Linen, oder...

Celery, äh, genau, man hat oft,

ähm,

äh, die Geschichte, dass man, äh,

nicht, dass man langlaufende, äh,

dass man langlaufende Jobs hat, die, ähm,

die ausgelöst werden von einem

Web-Request, und man möchte jetzt den User am Ende

aber nicht warten lassen. Also sowas

wie, äh, keine Ahnung,

hm,

ja, User lädt ein Video hoch, und man muss das jetzt in alle

Formate rendern, äh, dass, äh,

die halt so gebraucht werden für unterschiedliche,

fürs iPhone, für Android, äh,

ja, da oft nimmt man dann halt

auch irgendwie anderen Codec oder so,

äh, und in, in unterschiedliche

Auflösungen, je nachdem, wo man das irgendwie anzeigen will,

da möchte man nicht, und diese Render-Jobs

dauern halt, je nachdem, wie lang das Video ist,

sehr, sehr lang, ja, es lädt hier jemand ein Video, äh,

äh, das eine Stunde lang ist, hoch, dann möchte

er nicht, dass der Request, wenn das im Request

selber läuft, dass es nochmal zwei Stunden dauert, äh,

das ist sehr irgendwie komisch, sondern

dann nimmt man das Video her, sagt, okay, man macht

jetzt einen Task, äh, man erzeugt einen Task,

der, äh, irgendwie dann

unabhängig vom Web-Server läuft,

und der rendert dann halt irgendwie

das Video in die unterschiedlichen, äh,

Formate und so, und, äh,

sagt dem User schon mal, alles okay,

dann, dann upload es durch.

So, und für solche Sachen braucht man das.

Jetzt Video ist ein extremes Beispiel,

es gibt sicherlich eine Menge Beispiele, bei denen

das nicht ganz so schlimm wäre, aber

auch schon so nervig, dass man das vielleicht nicht haben will,

und dann... Also das hätte man gemacht, nicht einfach zur Arbeitsbienen

loszuschicken, die dann halt die einzelnen Tasks dann abarbeiten.

Ja, also die Tasks selber, äh, genau, da kann man sich auch

versuchen, welches Backend man verwenden

möchte, und Redis ist halt auch ein Backend,

sozusagen über das, damit Redis

als Queue verwendet, also diese, äh,

es gibt, also, Salary ist im Grunde

eine Task,

ja, es, äh, ähm,

besteht aus, äh, einem

Ding, was irgendwie die Worker koordiniert,

dann eine Menge von Workern,

und halt einer Queue, in die die Tasks

halt reinlaufen, also man, man

so einen Task erzeugt, dann, äh, landet der

halt in so einer Warteschlange, und

die Worker greifen sich aus dieser Warteschlange halt

ihre Jobs raus, ja, sozusagen, das sind Prozesse, die laufen

einfach irgendwie. Wenn wer am lautesten schreit, der wird dann als erstes

bedient, oder was? Genau, ja, das erste,

ja, äh,

der erste Worker nimmt sich halt irgendwie den ersten Job aus der

Queue und rechnet dann halt, bis er irgendwie

fertig ist, der nächste Worker nimmt sich den nächsten

und so weiter, bis halt keine Worker mehr da sind, die nichts

zu tun haben, und dann warten die Sachen in der Queue

halt einfach. Und die werden dann halt so mit der Zeit

abgearbeitet. Und, ähm, ja,

dann hat das Ding auch noch so ein Webfront in Flower, heißt das

irgendwie mit dabei, da kann man sich angucken, was ist denn

jetzt mal so ein Task geworden, haben die irgendwelche Exceptions

geworfen, gibt's da Tracebacks,

äh, sind die alle gut durchgelaufen, wie lang laufen die denn

so, so Basis-Statistiken,

wie lang laufen die denn durchschnittlich,

ja, äh, und all solche Sachen,

und, äh, also

das, wenn's funktioniert, ist es eigentlich

ganz, ganz gut, ja, kann man nix sagen,

ist eigentlich solide Geschichte, es ist

aber so manchmal, also, äh,

im Celery ist es manchmal so ein bisschen scharfkantig,

muss man, das hätte auch schon,

also wenn's nicht funktioniert, ist es nicht so geil,

muss man sagen. Also geht das nicht

für fast alle Dinge bei der Software? Ja,

es gibt manche Sachen, bei denen passiert einem das nicht,

dass die dann nicht funktionieren, also die,

zum Beispiel Redis ist dann so ein Stück von Software, das funktioniert

eigentlich fast immer super, ja,

es gibt selten den Fall, oder hab ich

noch nie erlebt, hab ich noch nie erlebt, dass Redis

irgendwie, äh,

etwas gemacht hat, und ich hab's nicht wieder

hingekriegt, also, ich hab's noch nicht

kaputtgekriegt, sozusagen, oder auch Postgres

ist so ein Ding, das kriegst du nicht kaputt.

Äh, Celery, äh,

hingegen, da installiert

man irgendwie, da wechselt man

irgendwie die Python meiner Version,

und dann geht gar nichts mehr.

Und, äh, alles

kaputt, ja, also,

und das ist, äh,

ja, oder man wechselt die Django-Version und nichts

geht mehr, ne, also es ist halt, äh,

also es ist halt deutlich fragiler, es ist nicht so, dass

man da, das, also bei, bei Celery

hab ich's schon häufig erlebt, dass es kaputtgegangen ist, und zwar

auch dann so kaputtgegangen ist, dass man's im Grunde

nicht mehr fixen kann, und das ist immer ärgerlich, wenn man

dann zum Beispiel eben nicht, Python nicht upgraden

kann, oder halt, äh, auch Django nicht upgraden kann,

weil halt ein Celery dran hindert,

das ist, und das ist schon öfters passiert,

also, ähm,

ja, muss

irgendwie so, also, wenn man's,

man, man kann's halt oft nicht vermeiden, dann

braucht man's halt, und dann, äh,

es gibt noch diverse andere Task-Queue-Geschichten,

Celery ist halt die verbreitetste

für Django, ähm,

ja,

äh, vielleicht lohnt es sich auch,

sich die anzugucken, ähm,

ich weiß es nicht genau, ähm,

aber, äh, ja, also wenn man's nicht braucht,

dann war's nicht unbedingt, äh, also es ist nicht,

es ist nicht unbedingt ne, äh,

ne Geschichte, die man aus der rein, aufgrund von

reiner Freude, weil's so viel Spaß macht, das zu benutzen,

verwenden sollte, weil das macht einfach nicht so

wahnsinnig viel Freude, und wenn man die

Abhängigkeit nicht braucht, sollte man sie weglassen.