Transcript: CSS / Markdown / Microservices

Hallo und herzlich willkommen bei einem Python-Podcast. Heute ist die 40. Jochen, wir haben ein Jubiläum.

Oh ja, herzlich willkommen Dominik. 40, das ist ja schon viel älter als wir sind.

Ja, fast.

Ja, zumindest teilweise.

Ja, noch.

Was wollen wir heute machen? Wir haben ja erst überlegt, ob wir irgendwas über Ensebild erzählen wollen,

aber das müssen wir wann anders, glaube ich, nachholen, weil

wir niemanden gefunden haben, der

sich mit Ansible so richtig gut auskennt, den wir ja gerne

als Gast gehabt hätten.

Wenn ihr also von Ansible Ahnung habt

und was erzählen wollt, dann sagt uns doch einfach mal Bescheid.

Das gilt auch übrigens für alles andere

Feedback, was ihr uns schicken wollt an hallo.pythonpodcast.de

Genau, wenn ihr ein Thema

habt, über das ihr gerne mal

gesprochen haben wollen würdet, dann könnt

ihr das auch gerne selber mit uns tun oder

jemanden nennen, den wir mal fragen sollen,

weil genau...

Wir haben zwar noch viele schöne Themen auf unserer Liste und so,

Aber wir lassen uns auch immer gerne bereichern mit neuen tollen Themen

Da müssen wir vielleicht nachher nochmal drüber reden, welche Themen das denn sind

damit Leute dann auch eine Chance haben, irgendwie zu sagen

ob sie jemanden kennen

Die können ja einfach ihr Thema bringen, auf das sie besonders Lust haben

Okay, dann sagen wir das jetzt zuerst, wo noch so viele Leute dazuhören, dass sie das mal machen sollen

Ja, es gibt ja so eine Burnrate

Genau, und dann am Schluss

ist ja keiner mehr übrig

Ja, aber was machen wir denn dann heute? Wir wollen eigentlich fast so ein bisschen mal wieder

kunterbunt voneinander reden

Zeugs besprechen

Eben so Metageschichten vielleicht tatsächlich mal wieder

Das haben wir jetzt auch schon länger nicht mehr gemacht

so eben, über was man mal reden könnte

oder ja, was wir so tun.

Ja, so richtig Meta,

ja, Meta bei was, ja.

Bei Podcast ist es nicht Meta, bei Python ist es

eigentlich so WebDev-Meta, oder?

Also was man so alles benutzen kann, an Tools

oder so. Ja, ich meine, wir machen ja

relativ viel Webentwicklung, oder ich

mache gerade relativ viel Webentwicklung

seit einer ganzen Zeit.

Ich weiß auch nicht, warum das so ist, weil ich

mache ja eigentlich auch viel Maschinenleutent-Kram und so,

oder habe auch mal viel gemacht, aber in letzter Zeit

und das ist irgendwie mehr Webentwicklung, obwohl das andere Ding ja auch gerade so halbt.

Ich weiß nicht, woran das liegt. Ich muss da vielleicht einfach mehr Machine Learning wieder machen.

Ich wollte gerade sagen, ich will erst mal den Job wechseln, Jochen.

Ja, das kann natürlich auch sein.

Ja, gut.

Vielleicht Webentwicklung ist eigentlich so ein bisschen Convenience-Software-Entwicklung.

Das kann man mal so ein bisschen dazwischen schieben.

Vielleicht musst du was Lippes machen.

Das ist nicht so schlimm.

Also Machine Learning auf Blockchain oder so.

Oh mein Gott.

Ja, das ist jetzt so, das weiß ich nicht.

Duo in Finale.

Ich weiß nicht, ob ich das machen möchte. Nee, eher nicht. Aber genau, vielleicht fangen wir einfach mit News an.

Ja, mit News.

Okay, warte mal, die Kapitelmarke News.

Dafür musst du dich jetzt aber ziemlich stricken. Das müssen wir noch optimieren.

Das muss ich. Der Raum ist noch nicht ganz optimal, das stimmt.

Okay. Also wir haben gerade ein Kapitelmarke.

Ich sehe schon, dass die Kapitelmarke irgendwie am Anfang jetzt sitzt und nicht da, wo ich sie eigentlich haben wollte. Irgendwie funktioniert das alles noch nicht so richtig.

Ja, in Melkrotte wird eher eine Laberfolge.

Ah, was ist denn da schon wieder kaputt?

Okay, ich stelle jetzt hier mal das Ding in Ultraschall auf.

Wir benutzen übrigens Ultraschall zum Aufnehmen.

Ja, Ultraschall 5, sehr gut.

Ein Plugin auf Reaper.

Ja, genau.

Wie produziert man Podcasts?

Das haben wir noch gar nicht.

Haben wir das schon mal gesagt, wie man einen Podcast produziert?

Oder wie wir unseren produzieren vielleicht?

Also Kurzversion ist tatsächlich,

wir nehmen das auf mit diesem Plugin für Reaper.

Reaper ist eine Software, die ist eigentlich kostenlos, aber...

Nein, nein, nein.

Ja, also in der Testversion, in der Evaluation-Version gibt es, also erstmal zum Ausprobieren kostenlos, ich wollte jetzt sagen.

Ja, okay.

Und dann gibt es halt dann dieses Plugin Ultraschall für Podcasts, was echt cool ist.

Und danach machen wir noch so Post-Production mit Auphonic.

Ja, und Shownotes schreiben und so, das machen wir auch so, leider nicht automatisch, sondern auf Auphonic.

Ja, aber das kann man ja

einigermaßen gebrauchen, dann kann man doch mal nachschauen,

was wir für einen Quatsch irgendwann mal erzählt haben.

Vielleicht ist da ein Schumanns drin, wenn das denn jemand

aufgeschrieben hat.

Genau. So, jetzt kann ich auch die

News-Kapitelmarke nochmal verschieben.

Ich kann ein schlechtes Gewissen haben.

Jetzt haben wir aber auch wirklich ein bisschen Meta über Podcasts.

Das ist doch schon mal etwas. Du wolltest bestimmt auch mal über andere Podcasts

gleich erzählen.

Ja, aber das war auch Meta.

Das war News.

Das ist ein bisschen Neues.

Also ganz schick.

Task Groups

gibt es jetzt, ist gerade gemerged

worden für Python 3.11.

Okay, was ist Task Groups? Fangen wir vielleicht erstmal

damit an. Naja, also

sagen wir so, es gibt ja irgendwie bei,

also es gibt eine Schwachstelle bei

Python Async

Geschichten, die halt da schon

oft irgendwie

ja,

Leute ein bisschen

depressiv gemacht hat, oder keine Ahnung, oder

geagert hat, ich glaube,

das ist am besten

Also zum Beispiel

Trio ist eine Bibliothek, die sich halt mit diesen ganzen Problemen

beschäftigt. Es ist halt auch schwierig.

Ja, Trio.

Nathaniel Smith hat die geschrieben.

Es gibt ja diverse Implementationen

in diesem Async. Ich habe jetzt ganz viel gehört, aber ich habe

immer noch nicht genau verstanden, was denn das Problem dabei ist.

Also das Problem ist halt,

also sagen wir mal so,

wir befinden

uns, was diese Async-Geschichten angeht, ja so ein bisschen

in einem ähnlichen

Stadium wie, als man

irgendwann mal angeführt hat, strukturierte Programmierung

zu verwenden, anstelle von

Gotoh oder so.

Das ist jetzt ein bisschen abstrakt.

Es ist jetzt so, als wäre es nebenläufig

ein zweiter Gedanke losgelaufen, der aber nicht mit dem anderen

wieder zusammengekommen ist, weil ich den nicht einsammeln konnte.

Ja, aber genau.

Also nachdem man strukturierte Programmierung, also mit Funktionen

und so oder Prozeduren irgendwie eingeführt

hatte, da musste man auch erstmal sich umgewöhnen oder so, weil man

das bisher immer anders gemacht hat. Also man strukturierte Programmierung

bedeutet, man schreibt nicht von oben nach unten irgendwas durch

und sagt dann, okay, geh wieder zu dieser Zeile und

macht da irgendwie weiter, sondern man

kennt das in logische Blöcke,

die man aufrufen kann.

Wo man am Anfang weiß,

was da reinkommt und am Schluss weiß, was da wieder

zurückgeht und sozusagen

damit man das halt nur noch...

Nennt man das eine Closure?

Nö.

Closure ist eine

innere Funktion,

die halt Zugriff

auf etwas hat, was

ja,

also du kannst zum Beispiel, wenn du eine Funktion

in der Funktion hast und du gibst jetzt sozusagen

die innere Funktion zurück,

dann hat die ja noch Zugriff auf den Scope der Funktion,

aus der sie rauskommt. Und da kannst du

jetzt Sachen drin definieren.

Also zum Beispiel Closures ist halt das allgemeine Prinzip

hinter, wie man Dekoratoren in Python

dann implementiert. Also Dekoratoren

machen das. Die rappen

sozusagen die Funktion, die man dekoriert,

in eine innere Funktion rein.

Bin ich mir gerade nicht ganz sicher, ob wir die Menschen, die uns zuhören,

jetzt nochmal abhören dabei, was weiß ein Dekorator sind?

Oder ob die das alles schon wissen?

Da können wir mal eine Episode dazu machen, die Quadrant, super Sache.

Eigentlich schon, ne? Ja, okay, dann machen wir eine eigene Episode dazu.

Also, man

man webbt dann quasi

die Funktion und dann, da die aufgerufen wird

und das Funktionsobjekt dadurch die Gegend gereicht

wird, muss man halt Objekte oder Dinge

reingeben können, rausgeben können und kann halt vorher

und nachher was machen.

Oder da irgendwelchen Kontext setzen, genau.

Und, ja,

also,

das ist nochmal was komplizierteres, aber

also Funktionen sind eigentlich relativ einfach, aber

trotzdem, wenn man das halt nicht gewohnt ist, dann muss man das umstellen

und es ist die Frage, wie arbeitet man damit, was macht man

jetzt eigentlich in einem Fehlerfall und so und all diese

Probleme haben wir jetzt nochmal so ein bisschen, weil

wir jetzt uns irgendwie überlegen müssen, okay

wenn wir jetzt async Sachen machen,

wie machen wir das denn richtig und

zum Beispiel ein Problem, was jetzt

halt den Leuten öfter mal auf den Fuß gefallen ist,

vor allen Dingen die Bibliotheken entwickeln,

als Endanwender oder

Endproduzer von diesen Geschichten

hat man das eigentlich gar nicht so oft,

aber kann sich ungefähr verdeutlichen,

also wenn man jetzt zum Beispiel, man hat halt so

also was man mit AsyncIO oft macht, ist sowas wie

zum Beispiel, also im einfachsten Fall

man hat eine Liste von URLs, die man abfragen möchte

und dann sagt man halt irgendwie

AsyncIO, oder man sagt halt

Gather den ganzen Kram

und kriegt dann halt das alles zurück.

Was passiert denn?

Was macht denn das Gather jetzt genau?

Das wartet, bis sie alle einmal

durch sind, alle Awaiten. Gather macht

Await eins nach dem anderen und zwar in der Reihenfolge, wie die Liste

drinsteht, oder das letzte.

Die Reihenfolge gibt es so ja nicht mehr.

Naja, aber

und die laufen ja nebenläufig und eins ist ja zuerst fertig.

Ja.

Und eins zuletzt fertig.

Und Geza wartet, bis alle fertig sind.

Genau.

Das

sozusagen, also man muss es halt noch erwarten,

aber das wartet, bis halt alle fertig sind.

Und die Ergebnisse sammelt das auch?

Oder gibt es da Ergebnisse?

Ja, also man kann da

durchaus auch, wenn da halt Ergebnisse

zurückkommen, jetzt weiß ich jetzt nicht genau was mit all den Dingern,

wenn da jetzt unterschiedlich, also normalerweise hast du eine Liste von Sachen,

wo das ist das gleiche, wo Liste von Responses

oder so zurückkommt. Dann kriegst du halt die Liste von

Responses dann halt

zurück, denke ich.

Wenn das jetzt unterschiedliche Sachen sein sollten,

weiß ich gar nicht so genau.

Ich bin gar nicht so sicher,

was dann passiert.

Wahrscheinlich kriegst du halt eine

Liste, der

wie auch immer die Liste aussieht.

Keine Ahnung. Aber das

Problem ist halt eben, und das was halt nicht so gut

geht, wenn du jetzt sagst

async-io-gether und jetzt passieren

aber mehrere Dinge. Jetzt hast du

zum Beispiel einmal einen Connection-Error irgendwie

bei nur einem URL,

sondern bei einem anderen Ding hast du aber

irgendwie einen, weiß ich nicht,

not authorized und bei einem anderen hast du

irgendwie

Authentication-Error oder was auch immer.

Du hast halt so unterschiedliche Fehlertypen.

Du kannst

jetzt aber im Interpreter, der kann

immer nur eine Exception weiterreichen.

Was passiert denn jetzt? Du kriegst die aber zu unterschiedlichen Zeitpunkten.

Wenn du jetzt hast

try irgendwas, gather,

was passiert denn jetzt, wenn du accept sagst?

Ja, dann sollte die accept, die zuerst

rausfliegt, sollte rausfliegen. Aber eigentlich sollte man die ja vorher

catchen, oder? Also innerhalb des

Dekor-Routines und nicht...

Ja, willst du ja aber auch nicht. Also du willst ja die exception

an der Stelle fangen, wo du irgendwas mit der machen kannst.

Also es hängt halt davon ab natürlich,

aber es ist halt so die Frage, wenn du die Frage

gefangen hast, okay gut, dann kriegst du sie ja auch nicht mehr.

Aber wenn du jetzt mehrere

Exceptions hast, die halt da

auftreten, was passiert denn dann? Und ja,

die Antwort momentan ist halt irgendwie,

ja, ist doof, weil

du kannst, es gibt

sowas wie Chained Exceptions, das sieht man manchmal

auch gerade bei so Webframeworks häufiger,

irgendwie, dass halt irgendwas eine Exception wirft

und dann dir sagt, ah, also

das ist passiert, also oder ein Test

passiert auch häufig,

während ich versucht habe, diese Exception zu werfen,

ist halt das passiert oder keine Ahnung,

oder sowas geht auch,

aber das bildet

das halt auch nicht ab, was du dann eigentlich können

müsstest, wenn jetzt irgendwie mehrere

unterschiedliche Exceptions halt aufgetreten

sind oder ein ganzer Baum, also im allgemeinen Fall

ein ganzer Grafbaum von

Exceptions, die halt irgendwie, so

das geht irgendwie nicht. Das kann auch tatsächlich der Interpreter

nicht. Und

ja, das ist halt ein Problem. Und dafür gab es

ein PEP

654, Exception Groups

and Except.

und der Code dafür ist jetzt

irgendwie

vor Woche oder so,

ein paar Tagen, gemerged worden

und alle so, huu, und das kommt in 3.11

und das bedeutet halt, dass man

jetzt quasi damit sauber umgehen kann. Also Trio

habe ich deswegen angesprochen, weil das war

halt so ein Ding, damit umzugehen.

Also der nannte seinen Ansatz

da auch irgendwie

Structured Concurrency und

der hatte dieses Konzept von Nurseries,

die man da benutzen kann, um halt damit dann sauber

umzugehen. Das hat eine Asynchroge, glaube ich, schon mal erwähnt.

Das hat eine Asynchroge und ich weiß nicht,

ob wir das wirklich, also ich glaube, das hat

damals schon niemanden so wirklich

gesagt.

Wahrscheinlich ist das jetzt auch nicht anders. Aber ich finde es

interessant und

es ist aber auch ein kompliziertes

Thema und

sagen wir so, die

Kurzfassung ist, es geht jetzt alles, also ab 3.11.

wird es deutlich besser. Es gibt da diverse Leute, zum Beispiel auch

der Juri

Selim Zvanov,

der mit

mit HQL und HDB.

Der hat auf Twitter relativ enthusiastisch

gesagt, so 3.11, das ist voll gut,

dass das jetzt drin ist. Wir haben schon seit Jahren Probleme

damit und jetzt ist es endlich

sauber gelöst und damit ist quasi

Python hat jetzt irgendwie

sehr gute Unterstützung im Vergleich zu allen

anderen Sprachen eigentlich.

Spielt da jetzt ganz vorne mit.

Und juhu!

Also das kann man

auf jeden Fall schon mal erwähnen, dass das irgendwie ziemlich cool werden

wird.

Jetzt muss ich nur noch verstehen, wie man halt so eine

Exception Group.

Ja, da musst du dir den

Pep angucken, da steht da schon, wie man

damit umgeht.

Ich glaube, man kann das ganz normal

in die Exception so auseinanderschreiben.

Wir haben jetzt relativ viel.

Also ich habe zwei verschiedene Exceptions.

Wir fangen mit zwei an, die gleichzeitig auftreten.

Also einmal, keine Ahnung, Autopsy-Grundverweigerung,

einmal Connection abgebrochen.

In zwei verschiedenen Threads.

Was machen die?

Du musst ja nicht Threads sein.

Aber ist auch egal.

Die haben auch dieselbe API oder auf eine andere API zugegriffen, ist auch egal.

Also Hauptsache, die schmeißen beide irgendwie Exceptions.

Aber der Zeitpunkt

ist egal oder nicht egal,

wenn das aufgetreten ist.

Naja, du kannst jetzt nach dem

Zeitpunkt ordnen, du kannst aber auch irgendwie anders ordnen,

je nachdem, wie du willst. Also du hast halt eine Exception-Group

und darunter hast du jetzt dann halt unterschiedliche

Exceptions.

Und dann hast du halt quasi einen Baum.

Eine Exception-Group kann halt wieder

unterschiedliche Exception-Groups drunter haben,

die dann wieder Exceptions drunter haben.

Das ist halt ein Baum von...

und wofür brauche ich das?

Naja, also wie gesagt, als Endanwender hat man

da den Fall, dass man das wirklich braucht, gar nicht so häufig,

aber wenn du jetzt halt irgendwie so eine High-Performance-Datenbank

Library

Geschichte baust, sowas wie

zum Beispiel

AsyncPG oder so, dann

kann das durchaus passieren,

dass dann halt

in solche Sachen reinläufst,

wo du dann gerne irgendwie was

gut, wo du zum Beispiel einfach noch

einen ordentlichen Traceback werfen wollen

würdest, wo man sehen kann,

was passiert ist.

Weil wenn du das auf 1 runter dampfen musst

und dann rausschmeißen und sagst Datenbankerror,

sagen wir mal so, gibt es eine Zahl zurück,

Datenbankfehler,

dann ist das nicht sehr hilfreich.

Du musst halt, aber alle Sachen

kannst du nicht angeben, weil du hast

nur eine Exception. Also weil die erste, die

quasi dann geracet wird, dann die die rausfliegt

und die anderen gehen dann unter, das wäre das Problem

sonst. Genau, ja. Ja, okay, und ich will halt

quasi, dass die durchgereicht werden. Du willst die

irgendwie behandeln können, ob du sie jetzt

rausprintest oder irgendwie darauf reagierst

oder so, ist ja nochmal eine andere Sache, aber du kannst

sie jetzt handeln. Also das wäre

quasi so, als müsste ich so eine Art

Exception Cache bauen und

dann irgendwann alle Exceptions in

diesem Exception Cache zurückgeben, anstatt die zu raisen,

die quasi in diesen Exception Cache reinspeichern

und ganz am Ende alle

Exceptions da drin sind in eine Custom

Exception zusammenfassen und raisen.

Keine Ahnung, wie das jetzt

dann Leute gerade machen.

Da gibt es unterschiedliche Ansätze wahrscheinlich,

aber jetzt geht es halt so, dass es

cool ist und sauber.

Ansonsten hatten wir noch

iPython,

erste Major Release seit drei Jahren

oder so.

iPython 8.

Ja, okay.

Ehrlich gesagt, so wahnsinnig viel Neues ist da gar nicht unbedingt.

Also außer Black ist irgendwie neu.

Da mussten sie auch ein bisschen zurückrudern.

Das hat Leute irgendwie auch böse überrascht.

Das haben wir doch letztes Mal noch gelobt.

Aber im Prinzip ist es eigentlich

schon richtig.

und

ja, ist es viel

deprecated worden von Dingen, die man

nicht mehr braucht und so. Und ich glaube, ich habe es auch schon,

ist es nur Beta, ist es noch nicht

stable, aber

ich habe es auch schon, also wenn man es einfach so

installiert, man pinnt es nicht runter oder so,

sondern man sagt einfach nur piv install

ipython und dann kriegt man das halt.

Und funktioniert bei mir auch schon super.

Ich verwende es schon

die paar Tage, die es veröffentlicht ist

auf jeden Fall und da hat es bisher immer getan.

Ja.

Genau, ja, ansonsten

so war es, ich glaube, wir haben jetzt irgendwie

super viele

Episoden in letzter Zeit aufgenommen,

weil gar nicht so viel passiert ist,

weil gar nicht so viel Zeit vergangen ist.

Ja, okay.

Ich weiß nicht, hast du noch irgendwas?

Wir machen nochmal Werbung

dieser Episode.

Oh ja, genau, das müssen wir dann jetzt auch machen.

Also, diese Episode kommt wieder mit der

freundlichen Unterstützung von NordVPN.

Ja, und

schnappt ihr den Exklusiv-Deal und ein Geschenk

obendrauf zum NordVPN-Geburtstag.

Gehe auf

https

nordvpn.com slash pythonpodcast

und sichere dir den

Wahnsinnsteal jetzt auch komplett risikofrei

mit 30 Tage Geld-Zurück-Garantie.

Also das ist

eine Geschichte, die man durchaus mal machen kann.

Also, ja,

NordVPN, VPN-Anbieter,

da

kann man sich zum Beispiel irgendwie im Urlaub

auch darauf verlassen, dass man dann weiter Netflix

gucken kann, was man ja sonst

manchmal hat man da so Probleme zu Video-Blocking und so

und damit kann man das irgendwie relativ

einfach umgehen oder halt auch wenn man

irgendwie sonst Konnektivitätsprobleme

hat, dann kann man aber auch irgendwie da

was gegen tun mit und

ja, hat viele

Server in allen möglichen Ländern

und so, also ist auf jeden Fall irgendwie

einer der größten Anbieter da in dem Bereich

und ja, kann man

ja einfach mal ausprobieren und auf

HTTPS,

www.notrpn.com

und die den Wandelstil sichern, der jetzt auch komplett

risikofrei mit der 30-Tage-Geld-Zurück-Garantie

ist.

Wunderbar.

Worüber reden wir denn heute?

Die ganzen Tipps,

Tools im Web und

CSS-Frameworks und

vielleicht fangen wir damit an.

Was für ein CSS-Framework benutzt denn du,

Jochen?

Ja, irgendwie gar nicht.

Ich habe vielleicht gesehen,

Podcasts zu unserer Schande in

Bootstrap, weil das Einzige, was wir gemacht haben

für Styling ist Import CDN

vom, also Bootstrap vom CDN.

Ja, das weiß ich gar nicht mal. Ich glaube, das mache ich tatsächlich nicht.

Aber das mache ich.

Oh Gott, das ist ja nicht schlecht.

Tja, wir müssen das

irgendwann mal anfassen. Weil ich würde sagen, das sollte man

natürlich eigentlich auf keinen Fall machen, sowas.

Aber weil

ja, das ist natürlich extrem unsicher. Das erinnert

mich an was?

Weiß das wirklich? Ja, ist das nicht so?

Ich meine nicht,

und

CodejQuery.com

Oh mein Gott.

Bootstrap CDN.

Oh nein.

Das war mir gar nicht so klar.

Kontrolle ist besser als...

Ja, ja, dankeschön.

Dann ist mir das jetzt auch bewusst.

Ich dachte, ach, sowas mache ich aber nicht.

Aber doch, mache ich schon. Kacke.

Ja, also Bootstrap ist raus.

Also sagen wir so, das benutzt man

halt natürlich dann, wenn man keine Zeit für irgendwas anderes hat.

Dann macht man einfach Import Bootstrap

vom CDN und dann sieht alles irgendwie ein bisschen

besser aus. Das hätte man gar nicht gestylt.

Aber auch nicht viel besser, ehrlich gesagt.

Ja, vor allen Dingen ist es halt das, was

in dem Django-Cookie-Cutter-Template

mit dabei war. Deswegen habe ich das vorhin gesagt.

Du benutzt ja kein Cookie-Cutter

von...

Eigentlich seit einiger Zeit nicht mehr, aber ich

habe es lange verwendet, ja.

Ich habe es auch ein bisschen mal ausprobiert. Das war nicht so ganz

mein Ding.

Also ich

benutze inzwischen gerne

irgendwie tatsächlich Startproject oder halt auch das,

das habe ich jetzt letztens wieder verwendet,

das Project Template,

weil man kann ja dem Startproject auch

Project Templates mitgeben von Johannes.

Das gefällt mir eigentlich tatsächlich auch ganz gut.

Und Cookiecutter ist einfach

es mir zu viel

Zeug, das ich irgendwie nicht brauche.

Also ich habe eigentlich meine eigenen Skeletons einfach

geschrieben, also so zwei, drei Templates für

Sachen, die ich manchmal brauche. Django mit Postgres, Django

Minimal, Farbpapier

und dann klone ich die einfach.

Ja, kannst du halt

auch machen, aber dann bleiben halt manchmal

so Reste übrig. Ja, aber das ist nicht viel.

Also ich weiß ja dann wo und ich habe mir das da so ein bisschen

weggescriptet, dann kann ich einfach

zwei Skripte ausführen und dann habe ich es einmal replaced

und dann schmeiße ich drei Dateien weg, die ich nicht brauche

und dann ist es gut. Also es ist halt mein

Zeug, ich kenne mich da ja auch aus und das geht aber dann wirklich schnell.

Und da ist halt aber auch dann das bei, was ich will.

Ja, also

es ist halt

irgendwie, also ich bin da noch nicht bei null.

Ja, andersrum ist es, du fängst halt bei null an und dann musst du aus allen alten

Projekten, wo du das benutzt hast, das jetzt mal reinkopieren.

Das geht auch nicht schneller.

Ja, aber

für sowas hast du ja normalerweise

ein Template, damit du das nicht

aber es ist wirklich, also ich habe auch

ich würde jetzt nicht sagen, dass es

da irgendwie eine Lösung für das Problem gibt, weil

es ist irgendwie, ich

habe inzwischen auch, also

am Anfang fand ich das

tatsächlich hilfreich, weil

es gibt ja so viele Settings in Django

auch, das ist halt echt eine Menge Zeug

dass man gar nicht weiß, wie man das alles

setzen soll und wenn man vor dieser Aufgabe

steht, ohne jetzt wirklich damit

mit schon langer Erfahrung zu haben.

Dann ist man so ein bisschen, also jedenfalls hatte ich das am Anfang

das Problem, du stehst halt wieder

wie so ein Ox von Berg Ja gut aber wenn du das jetzt von PyDanny nimmst also tats das Komplett mit Cookie Cutter das ist ja derselbe Typ der auch Two Scoops of Django Ja das Buch geschrieben hat oder die diversen

Bücher, die es jetzt in dem Thema gibt.

Aber

da ist so viel Zeugs drin.

Da ist so viel Zeugs drin.

Ja, die Hälfte brauchst du nicht.

Ja, aber das ist halt die Frage. Am Anfang

weißt du halt nicht, was du brauchst und was du nicht brauchst.

Ja, aber

für Anfänger würde ich auf gar keinen Fall

Klar, weißt du noch nicht, was du nicht brauchst, aber das würde ich

auf gar keinen Fall machen, weil ich würde blank Django nehmen

als Anfänger. Ja gut, also

für mich war das gar nicht so ein schlechter Weg,

aber inzwischen mache ich das halt auch nicht mehr,

weil ich jetzt sagen würde, okay, ich weiß jetzt, was ich

alles nicht brauche und ich brauche den meisten Kram.

Vor allen Dingen ein Ding, das mich

von dem Django-Kurkikata

komplett weggebracht hat, ist halt, dass die

halt irgendwann, das war auch nicht so,

das war am Anfang ja nicht so,

am Anfang war das komplett ohne Docker und

dann haben sie irgendwann gesagt, okay,

das jetzt für unterschiedliche Plattformen, das wird halt

und Jochen unterhalten sich über die Programmiersprache Python

mit drin ist, während der aktuellen

Geschichten, aber ja, also

genau, eigentlich ist das natürlich nicht so

schön. Ich habe jetzt auch letztens gesehen, wie groß

Bootstrap eigentlich ist, das war mir auch nie so klar, das ist ja

irgendwie alles ziemlich riesig.

Und dann eben hat das noch so

Dependencies of jQuery und so, das sind ja alles Zeugs,

das man heutzutage im Grunde nicht mehr wirklich haben will,

braucht und so, aber es ist halt

irgendwie dann alles immer noch mit dabei.

Ja, also Foundation gibt's noch,

das habe ich von Johannes mal...

Ja, Foundation ist so quasi

so ähnlich wie... Ja, auch so, du musst halt

eigentlich. Du schreibst halt nichts, importierst halt

einfach irgendwas vom CDN oder kannst es natürlich

auch vom Lokal. Und es sieht halt ein bisschen hübscher

aus. Man kann natürlich immer nasteilen, wenn man will.

Dann gibt es noch

Materialize und

UIKit.

Und das sind alles immer so große klassenbasierte

CSS-Sachen oder Post-SS oder so,

wo man halt dann seine Klassen,

vordefinierte Klassen hat, die dann irgendwelche tolle Magie

machen. Ja, oder Semantic

UI habe ich jetzt auch gesehen, dass das viele Leute

verwenden. AntDesign.

Das kenne ich nicht. Das ist

und das ist auch total schräg.

End.design.

Das ist so

was Chinesisches.

Das hat mehr

Stars aufgetappt als Django.

Und

ist irgendwie

in China verwendet. Das sind Millionen Leute.

Aber hier kennt man das Ding gar nicht so sehr.

Ja, ist auch eigentlich...

Wahrscheinlich verwendet es deswegen Leute,

weil es gute Dokumentation auf Chinesisch hat.

Man weiß es nicht.

Ja, mag sein.

Dann gibt es noch Bulma. Das benutzen zum Beispiel

viel von den VJS-Leuten, also wenn man

irgendwie jetzt auch V-Mastery oder so Kurse macht.

Da gibt es so ein paar Leute, die Bulma machen,

fand ich, das hat mich nicht so ehrlich

begeistert. Ist vielleicht eher so für...

Ja, aber das ist glaube ich in der gleichen Kategorie

wie eben, also das habe ich ja auch unter

Utility First,

CSS-Frameworks, genauso wie Tailwind.

Das ist ja auch... Ja, genau, aber

Tailwind würde ich sagen,

so mache ich das. Okay.

Ja, also ich finde es sehr, sehr toll.

Ja, ich habe auch viel Gutes gehört und habe aber auch Leute schon stöhnen gehört, also ich weiß es nicht.

Ja, also wir haben im Vorfeld jetzt kurz drüber gesprochen, du hast es mir so oben, Moment, also ich habe es schon nicht benutzt, aber ich habe ja gehört A und B und C und die haben gesagt, das ist doof und...

Ja, genau, aber das Problem ist halt immer so, bei diesen Entscheidungen,

ich meine, wahrscheinlich ist das einfach alles Unsinn, muss man irgendwas anfangen,

aber ich habe ja keine Ahnung davon.

Ich habe aber jetzt, reden wir da schon fünf Minuten drüber,

und ich habe ja auch eine Liste mir dann gemacht, weil ich dachte,

vielleicht muss ich da mal von 20 Dingern, die es hier irgendwie gibt,

die ich mir alle mal angucken muss.

Ich denke jetzt so, ich habe noch überhaupt nicht angefangen,

jetzt muss ich schon zwischen so vielen unterschiedlichen Sachen aushalten,

ich habe absolut keine Ahnung, was ich da machen soll.

Oh mein Gott.

Und dann eben, genau, soll man jetzt das selber machen?

soll man BAM machen, soll man irgendwie

Utility-First machen, soll man

ein Framework nehmen, soll man SAS nehmen, LESS nehmen,

Post-CSS, irgendwie

was auch immer. Ich weiß es doch

alles nicht und ich

habe keine Ahnung. Ja, ich würde tatsächlich

Table nehmen. Ja, gut, dann fange ich mal mit. Aber du hast ja gesagt,

das ist ja alles nur für Low-Budget.

Und ich bin ja eher

so, ich persönlich bin ja eher so

der High-Budget-Typ.

High-Buller, ja.

Finde ich, ich muss mich da schon

irgendwie so ein bisschen positionieren, ansonsten

nicht, dass man da irgendwie

mit dem falschen Ende rauskommt.

Das wäre nicht gut.

Ja, aber

ich weiß es halt nicht.

Es gibt noch andere Sachen. Es gibt noch die ganzen Mini-Dinger.

Habe ich jetzt gesehen bei

wie heißt der noch?

Andrew Johnson

hat das verwendet. MVP

CSS.

Ja, das kenne ich auch nicht.

Super Minimal und davon gibt es dann halt auch wieder ein paar.

Es gibt Mini-CSS.

Ja, da muss man immer CSS sein.

Also ich muss jetzt nochmal Talvand

nochmal loben, weil

es sieht hässlich aus auf den ersten Blick,

weil das das HTML so ein bisschen

bloatet. Du hast halt in deinem

HTML ganz viel mehr Klassen drin, die halt direkt

das Styling machen, aber dafür hast du halt eben

keine extra CSS-File mehr, musst nicht hin und her

switchen und eigentlich steht es meiner Meinung nach

genau da halt die Definition des

Styles drin, wo es halt hingehört und zwar genau

an dem HTML-Element.

Und das finde ich

super angenehm und da man eh

meiner Meinung nach ja immer so wieder

benutzbare Komponenten aktuell so hat.

Ist das mit der Redundanz hier auch

nicht so schlimm und

ja, wenn du dann halt so ein Hot Reloading

weit noch nebenbei anhast, dann

siehst du halt jede Änderung der

Farbe, schreibst halt Red

als Klasse hin und dann

ist es Rot und dann schreibst du

Red wächst mal Blau und dann ist es direkt Blau

und das ist einfach, das ist so ein bisschen

wie den 90ern HTML-Coden.

Da muss man das ja auch alles noch

direkt hineinschreiben.

und ich mochte das.

Okay, ich habe das weder in den 90ern gemacht, noch jetzt

oder dazwischen irgendwann, aber gut.

Na ja, jetzt

muss ich wohl doch irgendwie mal.

Ja, das musst du auf jeden Fall mal angucken.

Wir haben ja auch eben noch über Winly kurz gesprochen,

das hast du ja auch noch gehabt. Da gab es ja eine lustige...

Also über Tailwind,

da gab es einen neuen Releaser, das hätten wir in die News packen können.

Ja.

Es gab eine

Working Draft Episode letzte Woche oder so was

über Tailwind

CSS3

wo auch irgendwie der

Tenor war, so eigentlich ist ganz gut und

die Vorteile sind halt irgendwie, dass man jetzt nicht mehr

also früher war es so ein Default-Fall, hat das halt irgendwie

immer

die gleiche Größe an CSS ausgelegt.

Ja, man musste halt manuell purgen die

CSS-Dinge, die man nicht haben wollte.

Die musste man dann weg purgen, dass der

die Falle nicht so groß wurde, ja.

Genau, und das passiert jetzt irgendwie alles automatisch

und man

muss auch nicht mehr Node.js verwenden, sondern

es hat irgendwie Standalone

Command-Line-Utilities

irgendwie für all die Sachen.

Und das ist ja schon sehr nett.

Da dachte ich auch so, oh, das klingt aber gut.

Und dann eben hieß es da auch, ja, das kommt

aber von den Leuten von Winnie oder so.

Ja, also Winnie hat ja Tailwind geklaut und dann

Sachen so ein bisschen halt faster gemacht

vielleicht oder so, so ein bisschen mehr Opinion reingebracht.

Dann haben sie das halt wieder zurückgeklaut.

Und dann haben sich die Winnie-Leute

beschert, dass sie nicht gecredited

werden für diese Geschichten.

Und dann hat irgendjemand anders gemeint, so, ah,

ihr habt das auch nur von mir wieder geklaut.

und so. Keine Ahnung.

Das verflüstert sich auf einmal so, als wären das jetzt irgendwelche Geheiminformationen.

Nö, das ist es nicht. Aber ich,

keine Ahnung.

Also ich mag tatsächlich auch die Bezahlsachen von

Table & Consent kennen. Es gibt ja so vorgefertigte

UI-Komponenten, die man sich kaufen konnte.

Und das Projekt zu unterstützen ist von denselben Leuten, die

das Projekt geschrieben haben.

Ja, es gibt ja auch

so ein tolles Buch, irgendwie Refactoring UI

oder so. Ja. Habe ich mir

auch irgendwann mal gekauft, aber habe ich dann nicht gelesen.

Vielleicht sollte ich das auch mal machen.

Vielleicht sollte ich damit immer starten.

irgendwie mal ein Buch lesen oder so. Das könnte vielleicht

hilfreich sein.

Eine Geschichte, die tatsächlich interessanter

aussieht als diese Myriade an

unterschiedlichen CSS-Arten,

Frameworks, Minimal-Dinger, die man

so benutzen kann, die ich

letztens gesehen habe, ist

Missing.style.

Und zwar, weil das halt

aus dem HTMX-Umfeld kommt.

Und da Leute

sich überlegt haben, okay,

das fehlt halt noch. Also wenn man

HTMX macht, das mache ich jetzt auch relativ viel,

und damit bin ich eigentlich super

zufrieden mit und ja, aber wie macht man das

denn jetzt, weil da ist ja auch viel

Animationsgeschichten oder so drin,

die das dann Sachen verschwinden, wenn man irgendwo drauf

klickt oder auftauchen und so

Transition-Effekte und so und

ja, da haben sie überlegt, okay, dann brauchen wir eigentlich

genau dafür eins, aber wir wollen vielleicht nicht

so ein super

all-in-one

Riesending haben, sondern nur für die Sachen,

die wir da benutzen, irgendwie so ein

CSS-Geschichten mitrahmen und

sozusagen der Missing-Link

irgendwie.

Soll das irgendwie so sein? Das kann man sich auch mal

angucken. Also da werde ich auf jeden Fall auch mal drauf gucken,

was die da machen. Und das

klang auf jeden Fall interessant, weil das fehlt halt tatsächlich.

Also bisher muss man dann halt diese ganzen

Transition-Geschichten

halt irgendwie in sein CSS mit reinfrickeln

dann. Und wenn das halt automatisch

alles da wäre, wäre natürlich schon nett.

Ja.

Genau.

Ansonsten, tja, ich weiß nicht.

CSS haben

Tja.

Ich muss mich damit mal auseinandersetzen.

Ich komme nicht mehr drum rum.

Das erzählst du mir schon seit Jahren.

Seit Jahren.

Und dann habe ich doch immer wieder was anderes gefunden.

Ja.

Ja, es ist...

Es lässt sich aber, glaube ich, inzwischen echt nicht mehr vermeiden.

Ja, wie zum bisschen. Also deswegen

empfehlen wir immer noch Tailwind.

Hast du das schon gesagt?

Ich bin ein kleiner Fan davon.

Es war so ein bisschen...

Ich konnte CSS sehr, sehr lange überhaupt nicht leiden.

und es war irgendwie mega hässlich.

Und dann fühlte sich es so an,

wie ich es machen will. Das ist so wie bei Python,

wo ich relativ schnell wusste,

okay, so will ich es machen.

Ja. Das ist immer dann, wenn man

gar nicht weiß, wie es geht und dann findet man was,

was irgendwie cool ist. Ich weiß auch nicht.

Vielleicht ist man auch völlig auf dem Holzweg, weil man keinen hat,

der einem erklärt hat, wie es richtig ist. Aber vielleicht ist es auch

manchmal gar nicht so schlecht, wenn man da so ein bisschen seiner Intuition folgt.

Ja, am besten

ist es wahrscheinlich, man muss irgendwas machen und dann

schauen, ob man

den Kurs korrigiert, wenn es irgendwie nicht mehr gut

gut. Ja, das sollte schon

möglich sein, dass man seine Meinung auch wechseln

kann. Das ist, glaube ich, schon...

Wir werden

uns weiter

Dinge angucken und dann sagen wir

Bescheid, wenn wir irgendwie das perfekt gefunden haben.

Ansonsten, ja,

ich meine, keine Ahnung, ich könnte ein bisschen was erzählen

zu den Sachen, die ich so mache. Warum gucke ich

mir eigentlich CSS-Geschichten an?

Ja, erzähl mal, warum guckst du dir CSS-Geschichten an? Ist ja langweilig.

Jochen hat schon was zu tun.

Ja, ich habe ja diverse

Projekte, ja.

aber

genau, momentan

also eine Geschichte, die ganz

interessant ist, also HTMLX

das beeinflusst halt

so viele Sachen, weil das halt

mit HTMLX sagen wir die nächsten Trinkspiele, Jochen

wenn ich das sage, was

ja, stimmt schon

aber, naja, so

weil vieles

so gerade, ich hatte mal irgendwann vor Jahren

also das ist zum Beispiel wieder eins von diesen Beispielen

so ein Bookmarking

angefangen und das macht halt auch so viel

mit Bootstrap

und so und jQuery

und ist halt alles ziemlich hässlich,

was Frontend-Geschichten angeht.

das im letzten Moment angefasst,

wieder auf aktuellen Stand gebracht und

da könnte man wahrscheinlich mit HTML

sehr viel machen und dann ist halt die Frage,

kann man dann nicht den ganzen anderen Kram gleich mit

rausschmeißen, also sowas wie dieses ganze

jQuery-Graffel und irgendwie

Bootstrap und so, das wäre doch eigentlich ganz nett.

Und dann ist halt die Frage, okay, was macht man in der Hand?

was sind denn deine CSS?

Genau, genau.

Weil genau, perfekt,

dann ist auch dafür auch super geeignet.

Du hast ein Snippet,

das du per HTMLX rausrennen kannst

und was schreibst du in dein Snippet rein?

Ja, genau,

also das wäre natürlich nett,

das sind halt so Sachen,

die Tailwind-Blend machen,

ist halt,

dass es,

wenn es im HTML-Strom steht,

dann kann man es eben auch direkt mit,

man muss halt nicht

ein neues CSS mit ausliefern.

Genau,

und du musst auch nicht jedes Mal

in das,

irgendein großes CSS,

in das du schon ausgeliefert hast,

genau die Sachen reintreiben,

sondern schreibst halt genau das,

was du willst,

in dein,

ja.

Aber du hast eben auch gesagt, also ja, also die großen Designer, die sich die ganz tollen Konzepte überlegt haben mit ihren Style Guides, die könnten eventuell sagen, dass du dann einfach trotzdem den Button kleiner machst, obwohl das verboten ist im Style Guide.

Ja, ich weiß, ich habe ehrlich gesagt

keine Ahnung, wie man das alles wirklich macht, aber naja

Ja, aber genau

das wäre so

das war so einer der Gründe, warum ich da nochmal drüber nachgedacht habe

dann genau

war auch sowas wie

ja

diese, dafür würde ich gerne

so eine Landingpage bauen, halt irgendwie

Podcast-Hosting

Service-Geschichte

und da braucht man dann ja auch vielleicht ein bisschen

mehr Design-Wumms und dann

Es bootstrapft vielleicht irgendwie nicht das Richtige.

Also was wir da machen, ist

Designer fragen.

Dann machen die uns einen Entwurf,

Design. Und dann machen wir das

in Tablet.

Ja, irgendwie

sowas.

Da helfe ich dir gerne bei.

Du hast noch ein paar Sachen entdeckt, ein paar Pics fast.

Ja, aber genau.

Kann man auch einfach mal raushauen.

Gibt es ja genug Gelegenheiten für andere Pics.

Mermaid. Mermaid habe ich jetzt

letztens gesehen.

ziemlich coole Sache, das kann ich noch nicht.

Was man damit machen kann, ist Markdown-Enhance

um sowas wie Diagramme.

Ja, genau. Und das kann halt

auch diese Diagramme, die Arten von Diagrammen,

die man halt... Also das, was

ihr von Draw.io vielleicht kennt so ein bisschen oder so.

Wenn ihr so, weiß nicht, ob das in der Komplexität

geht, aber richtig coole Sachen,

die man echt gut dastehen kann.

EM-Diagramme, Flowcharts,

sowas. Einfach als Markdown

schreiben, so ein bisschen runterschreiben und dann könnt

ihr das auch direkt rennern lassen. Auch von

sowas wie GitHub. Ja, also

und

mit Graphics oder Dot irgendwie hat das

dann gerendert, aber das ist alles

nicht so...

Also für das ERM, die Rahmen direkt rausrennen lassen

aus den Models, ist das natürlich schon nett. Also wir reden ja

gerade über Mermaid, dass das glaube ich nicht macht.

Nee, da machst du es von Hand, aber da hast du halt dann auch mehr

Kontrollmöglichkeiten. Also insofern...

Ja gut, aber ich will jetzt natürlich nicht jetzt irgendwie,

wenn irgendjemand einfach kurz das ERM sehen will,

dann explotiere ich halt einfach aus meinen Dango-Models.

Aber ja, du hast natürlich recht.

Viel schöner, wenn man das vorbereitet und am Anfang,

bevor man die Models hat, kann man das

ja vielleicht bauen so.

Naja, ist eher so, weil die Frage ist, was willst du in deiner Dokumentation verlinken?

Und ein automatisch

generiertes Ding in der Dokumentation ist halt

irgendwie nicht so

super. Die wichtigere Frage wäre, liest jemand

die Dokumentation?

Ja, das ist auch, vielleicht nicht.

Ja, wenn nicht, dann mache ich es automatisch, weil

dann muss ich ja keine Arbeitszeit reinstecken. Wenn doch,

dann sollte man es ordentlich machen. Aber das ist immer ein bisschen

die Frage, weil einige Leute wollen die unbedingt haben,

aber niemand guckt rein.

Dann ist es halt nur für einen selber und dann weiß ich nicht,

ob ich das dann...

Ja, aber, also was mich halt freut, ist, dass es jetzt auf jeden Fall ein Ding gibt, wo man, also sonst habe ich mich immer gefragt, ja, nehme ich Draw.io oder nehme ich irgendein anderes Tool oder nehme ich halt irgendwie irgendein Desktop-Ding, was ich halt habe und dann mache ich das als PNG raus oder als SVG, nehme ich lieber ein SVG oder weiß nicht so genau und dann, das sieht aber auch wieder ganz anders aus als alle anderen Diagramme, die ich sonst so gemacht habe, also Mist auf dem Hintergrund funktioniert das aber nicht, halt diese ganzen Probleme und das ist dann halt alles los, wenn man das mit Mermaid macht.

Ja, also das ist wie gesagt Master und ihr könnt auch sowas machen wie verschiedene Projekte, wie lange wollt ihr die ins Kedulen und dann nebeneinander, das finde ich echt sehr cool, also ich muss mir das unbedingt angucken, weil ich halt diese Tasks, die hintereinander kommen, wie lange brauchen die denn, kannst du so ein Ad-Gent oder sowas für verschiedene Projekte bauen kann in Markdown und wir benutzen ja eh für alles jetzt Markdown, nicht wahr Jochen?

Ja, ich weiß nicht so genau.

Nein, zum Schreiben, nicht?

Ja, meistens, also

genau, ich habe jetzt auch

MPDocs mehr dann angeguckt und damit geht das halt auch

da gibt es so ein Plugin für

Data-Templates geht auch

PDF geht, sogar

so Richtung Latex-Templates geht

es geht, was noch?

Was brauchen wir noch? PDF natürlich, aber

Präsentationen geht

Naja, oder Notebooks verwende ich halt auch

Markdown viel

Klar, aber

sagen wir mal so, also für Python-Dokumentation

traditionell verwenden Leute ja dann

Restructured Text. Ja, aber das ist so hässlich.

Ja, es ist hässlich, aber

es kann halt viel mehr als Markdown.

Und es gibt halt, die Leute sagen halt

immer so, ja, also Markdown

nett, aber es kann halt nicht die Sachen, die ich brauche.

Daher nehme ich lieber, also gerade was

Links angeht und so,

daher nehme ich lieber Restructured Text.

Ich glaube auch, das ist immer noch

das, was am häufigsten verwendet wird.

Also wenn man irgendwie Dokumentationen von Projekten anguckt,

dann ist es meistens Restructured Text.

Aber ich hatte auch öfter mal Restructured Text mit Trinks oder so.

Ja.

versucht, aber...

Ich verstehe,

wo das Problem ist, ja.

Also es schlägt dann keiner mehr. Also Markdown kann man irgendwie

besser...

Ich weiß nicht, Research-Dischekt wird es nicht schaffen.

Keine Ahnung, aber...

Bin ich mir sicher. Also Markdown kann man so

super viele Anwendungsfelder haben. Man kann das halt einfach

sein GitHub hochladen, es ist direkt gerendert.

Man kann, weiß nicht, es gibt so Typora oder so,

ich glaube, der ist leider, der war tischendurch frei,

ich glaube, der ist jetzt leider auch

proprietär, aber

da konnte man wie so ein Schreibprogramm

seine Eltern überreden, wenn die

irgendwas schreiben wollen und kein Word brauchen, hey, schreib doch

Depora, dann hat die Markdown-Files voll toll.

Und die haben es gar nicht gemerkt, weil das so ein Wolf-Misky-Editor

für Markdown hat das. Richtig schön.

Und so war es halt. Und ja,

Obsidian vielleicht noch.

Und das halt so eine grafische Visualisierung

von deinen Markdowns macht, wenn du das

möchtest. Und dann kannst du so ein bisschen sehen, woran du arbeitest.

Oder wie die Themen untereinander verknüpft sind. Die Links können

man... Kennst du das Zettelkasten-

Prinzip?

Äh, Luhmann ist das

irgendwie, ne? Oder... Ich weiß nicht genau,

wie heißt?

Ach, jetzt können wir es nicht erklären.

Jetzt müssen wir

ein eigenes Amt hier haben.

Doch, ich glaube,

du kannst auf jeden Fall Sachen da richtig

einsortieren und hast durch die Verknüpfung direkt

viel schnellere Sachbehalte

miteinander gebündelt.

Ja.

Ja, Luhmann kann sein, dass das richtig war, aber

wie genau das ging, weiß ich jetzt nicht genau.

Jedenfalls unterstützt

auch das deine Ablage an dieser

Methoden.

Mein Notizblock SimpleNode, ich muss

auch Markdown, Vendable und so.

Ja, also es gibt ganz viele Kleinigkeiten,

die in diese Markdown-Welt reinspielen und diese

schlimmste sind alle Interchangeable

und das ist, also ich bin auch ein großer

Fan von Markdown, habe ich ja schon gesagt.

Nee, aber ich glaube, man kann das irgendwie

durchaus so raushören, wenn man da

ganz, ganz genau mit der Lupe

draufkommt.

Ja.

Ja,

ja, es läuft

momentan alles ein bisschen auf Markdown hinaus.

mal schauen.

Genau, auch schön ist, dass es halt auch in GitHub-Geschichten

funktioniert, dass es auch irgendwie Standard-

Integration, Standard-Message-Integration

an, das heißt, wenn man das einfach so reinschreibt, dann

hat man das halt auch in Issues oder halt in

irgendwie, ja, Markdown, was halt

auch von GitHub gerendert wird.

Ja, überhaupt

aber das ganze Dokumentationsthema

ist ja auch so, in letzter Zeit habe ich mich

ein bisschen

mit MakeDocs

beschäftigt, aber halt

auch überhaupt mit diesem Ding, dass man das

halt vielleicht mal tun sollte, weil

also meine Ansicht dazu bisher war ja eigentlich

immer so Dokumentation, ah ne, lieber nicht.

Ist ein bisschen

zweifelhaft vielleicht und

inzwischen denke ich mir so,

naja, vielleicht ist es doch nicht so schlau.

Und genau,

da hatte Simon Willison

auch irgendwie diverse Artikel jetzt

in letzter Zeit in seinem Blog einmal

irgendwie bessere Release Notes

schreiben. Da versuche ich mich

jetzt auch so ein bisschen dran zu halten.

Ja, das finde ich schwierig. Also bei mir steht auch

in den meisten Commits nur Schrott drin wie

FixedSomething oder FixedFinal

oder FixedAgain oder Typo.

Ja, also ich versuche es immer. Also es gibt dann immer

einen Commit, der ist ordentlich

und 15 dann, die sind irgendwie

so Fixes davon. Ich glaube, man kann die irgendwie

stacken.

Du kannst sie hinterher

squashen, wenn du das halt

in einem Pull-Request zusammenfasst.

Ja, aber das mache ich zum Beispiel nicht.

Ja? Ja, das würde man in Pull-Requests

machen. Das ist bei mir relativ egal,

wenn ich der Einzige bin, der auf so einem Branch ackert, dann ist das

für dich burschen. Ja, klar, klar.

Ja, würde ich auch sagen. Also normalerweise

irgendwie mache ich das halt auch nicht, wenn ich da

irgendwie alleine... Aber wenn man sich jetzt überlegt,

eigentlich möchte man ja vielleicht

irgendwie die Entwicklung auch skalieren können.

Ja, das ist sehr sinnvoll,

dass man gute

Commit-Messages hat, wo auch was passiert

und nicht nur zwei Leerzeichen gemittet werden. Dann müsste man

auf jeden Fall seine Commits alles squashen

und die ordentlich machen und so Aber so Commit ist jetzt bei mir so die gehen eigentlich finde ich Die sind gar nicht so schlimm Aber die sind auch ganz okay Ich habe mich ja mal die Zeit mit euch

unterhalten. Das ist auch schon ein paar

Jährchen her, glaube ich. Und zwar, ob man die in Präsenz

oder in der

Vergangenheitsform formuliert.

Ja.

Weiß ich auch gar nicht mehr. Das Ergebnis war, Präsenz wurde

bevorzugt. Präsenz, ja, kann sein.

Ich weiß jetzt gar nicht, was ich...

Dieser Comment-Trick ist dissonierend, anstatt dieser

hat das gefixt.

Ja.

Aber das ist ja nicht das gleiche wie Release Logs.

Release Logs ist nochmal eine andere Geschichte.

Ja, aber wann macht man das zum Beispiel?

Wann schreibt man quasi sein...

Ja.

Die Fixliste.

Wenn du

eine Release machst.

Ja, aber auf Semantic Version,

auf welcher...

Semantic Version ist halt eine Sache.

Braucht man das? Nein?

Warum nicht?

Naja, weil es ja auch nicht wirklich hilft

und also gut, auch da gibt es

eine Menge Leute, die mittlerweile

halt irgendwie einfach

fortlaufende Geschichten machen.

Ein bisschen Pseudo ist ja ganz okay.

Wenn man zum Beispiel weiß, man hat jetzt nur ein bisschen was

gefixt oder arbeitet an so ein paar

Sachen rum, dann macht man

immer so die Patch-Version.

Wenn man jetzt quasi ein paar neue Features eingebaut hat, würde ich

sagen, schon Miner nach oben.

Machen wir einfach Miner einen hoch. Neue Features,

Miner.

Und Mater ist Breaking Change, also es geht irgendwas

nicht mehr mit früher, dann ist es major.

Ja, wenn man das so machen will,

klar, aber die Frage ist halt,

ob das jetzt sinnvoll ist oder nicht, das ist halt nochmal

eine andere Frage. Es gibt Leute, die machen es so, machen es anders.

Aber egal, wie man es macht,

also Release Notes zu schreiben,

ist wahrscheinlich immer eine ganz gute Idee, egal, wie man es

macht.

Und auch da ein Datum zum Beispiel dazu

zu schreiben und dann halt noch, da kann man sich

auch die Artikel mal im Detail angucken.

Ja, stimmt, sollte man machen.

Idealerweise sollte da die User-Story beschrieben sein,

die gefixt wurde oder die dazugekommen ist.

ist auch nicht gut. Es sollte

so sein, dass...

Ein Satz zu dem Punkt.

Ein Satz, okay, das ist okay,

aber es sollte halt nicht irgendwie, genau.

Man kann ja durchaus die Issues

und so reinschreiben.

Der User kann sich jetzt

auf unserem Backend einloggen.

Oder sowas wie, der User

kann jetzt den Filter

so bedienen, dass er alle möglichen...

Das ist halt die Frage, für wen schreibst du das?

Das sollte man sich vielleicht auch überlegen.

und die Devs.

Ja, aber die interessiert das doch nicht, was die User-Story ist.

Also ich würde sagen, aus einer technischen Perspektive

sind die User-Stories doch eigentlich komplett uninteressant.

Ja, aber das wäre die technische Formulierung von

du kannst jetzt in diesem Formular das und das, die Auswahlfehler.

Also technisch würde ich reinschreiben, was tatsächlich passiert ist,

was man geändert hat.

Oder so, die Cop-Messages aneinander kleben.

Nee, nee, nicht die,

aber halt sozusagen reinschreiben,

was da passiert ist.

Aber aus Business-Sicht ist das halt uninteressant.

Aus Business-Sicht ist halt nur interessant,

was ist denn jetzt mit unseren User-Stories passiert.

aber aus technischer Sicht sind die User-Stories halt relativ irrelevant.

Das finde ich gar nicht.

Ne? Okay, gut. Interessant.

Ich weiß es nicht so genau.

Ich würde sagen, dass die meisten Open-Source-Projekte

sowas gar nicht haben. Die haben gar keine User-Stories oder sowas.

Ja, okay, aber

das, was damit gemeint ist, weil tatsächlich ja das Feature,

das man baut, vielleicht das ist, was man dann umsetzt

und wie man das, also das würde ich jetzt

in den Release-Log reintreiben, welches Feature jetzt

umgesetzt ist.

Ja, wie gesagt, aber ich glaube,

es würde wahrscheinlich schon viel helfen, wenn man sich

überlegt, an wen richtet sich das eigentlich?

Wer soll das lesen?

Kann man ja zu unterschiedlichen Ergebnissen kommen.

Kann man zu unterschiedlichen Ergebnissen kommen.

Nutzer lesen oder die Devs lesen.

Und zum Beispiel

ein Ding, das mich jetzt gerade interessiert,

deswegen beschäftige ich mich damit auch so ein bisschen,

wenn man jetzt Entwicklung skalieren möchte,

dann

ist es vielleicht gar nicht so schlecht,

zum Beispiel eben auch andere Artikel,

ich weiß jetzt gar nicht mehr, wie der Titel von dem war,

hat er so, ja, also

er schreibt immer, seit einiger Zeit

und macht er immer GitHub-Issues auf für alles, was er macht.

Und einfach, um halt einen Punkt zu haben, wo er alles sammeln kann,

was zu einem bestimmten Ding gehört.

Und zwar nicht nur...

Was ich ganz gerne mache, das muss man halt immer ein bisschen einstellen,

ist To-Do-Kommentare im Code.

Aber die mit GitHub-Post-Assessing, dass ihr einen Hook habt,

dass ihr automatisch aus meinen To-Dos im Code Issues erstellt,

auf GitHub und die automatisch wieder zumacht,

wenn das To-Do da verschwindet und das CD

automatisch auch nummeriert und das dann halt auch in dem

Commit mit ergänzt.

Das heißt, er schreibt dann quasi an den To-Do die

Issue-Nummer mit dran und

dann kann man quasi darüber auch direkt sich linken

lassen, wenn man das einstellt, auf den Issue

auf GitHub und sich den angucken und die Diskussion dazu angucken

und hat aber das im Code stehen und muss halt

nicht zwei Sachen pflegen, sondern du kannst halt einfach im Code

das dann bereinigen

und dann ist halt geschlossen

und sowas. Und das finde ich

sehr gut.

Ja, wenn du eine Stelle hast an einem Code, wo du das hin...

Aber es gibt ja auch viele Dinge, die sind...

Kannst ja nicht an einer Stelle festmachen.

Aber gut, ja.

Wie man es macht, ist ja letztlich...

Du kannst natürlich auch ein extra machen und dann halt referenzieren.

In einem Commit oder so. Aber, ja.

Genau, und das kannst du ja mit dem

Issue auch super machen. GitHub macht das ja gut.

Also es erinnert dich niemand daran, noch extra Issues aufzumachen,

wollte ich da mal sagen.

Ja, ja. Nee, klar.

Ich weiß gar nicht...

Wie man es jetzt macht, das kann man

halt machen, wie man will.

aber was ich daran interessant fand

ist halt, also einmal sagt er halt

warum er das macht

ist halt, dass er einen Punkt haben möchte

sozusagen

an dem alles andere hängt

und GitHub macht das ja automatisch für ihn

das alles zusammenzuführen, wenn er irgendwo dann halt

die Issue-Nummer mit reinschreibt

und

der andere Punkt ist halt

er hätte gerne dann daraus einen Pull-Request

und dann sozusagen einen perfekten Commit

der halt das dann halt irgendwie handelt

wo er dann halt

sozusagen alles zusammen hat, was

Änderungen an Dokumentation,

Test, Code gemacht werden muss,

damit das halt irgendwie dann,

damit er das Ding zumachen kann.

Und

dann ist der

Issue sozusagen eigentlich auch so eine schöne

Geschichte, um halt

da reinzuschreiben, was dann

überhaupt passieren soll. Auch eine gute Gelegenheit,

um sich Gedanken zu machen, was man eigentlich machen will.

Und allein, wenn man sich

überlegt, okay, ich mache jetzt ein Issue auf und schreibe mir erstmal auf,

was denn jetzt dazugehört, dann

erledigen sich halt viele Sachen schon, weil man dann anfängt,

so ein bisschen gezwungen ist, darüber nochmal nachzudenken

und dann vieles sich dann auch schon wieder erledigt.

Wenn man so anfängt nachzudenken, ist ja manchmal so ein bisschen

nicht so

schlecht. Oft ist es halt so, dass

man das dann später merkt, wenn man irgendwie anfängt zu entwickeln

und dann später merkt man so, oh, das hätte ich jetzt alles

eigentlich gar nicht machen müssen. Aber

also, das

fand ich ganz nett.

Vor allen Dingen, ich habe das jetzt zum Beispiel

für einen Ding, ich habe so einen Podcast klein geschrieben.

Ich weiß nicht genau, warum ich das jetzt gemacht habe.

Wahrscheinlich.

für diesen Ding, Jagni.

Ich weiß nicht genau, wo ich den noch gemacht habe.

Ja, Jagni könnte sein.

Oder halt auch einfach

so Standard-Jag-Shaving

könnte auch gut sein.

Ja, eben.

Ich kann mir vielleicht gleich nochmal eine Abschweife

nicht so unternehmen.

Aber genau.

Und da habe ich mir dann gedacht,

okay, das war dann halt auch das Richtige.

Das mit den Issues mache ich jetzt vielleicht auch mal so.

Ich lege einfach schon mal ein paar Issues an.

Wenn jemand vorbeikommt und da drauf guckt,

dann kann er das vielleicht einfach so machen.

einfach, damit Leute halt einen Ansatzpunkt haben.

Wenn du halt einfach so eine Code-Basis hast, dann weißt du ja gar nicht,

selbst wenn du dann irgendwas machen wollen würdest,

was du dir jetzt da machen sollst.

Die meisten Leute, die gehen ja nicht hin und gucken,

oh, was gibt es denn schon für Git-Apps für coole

Podcast-Clients? Oh, der ist auch total unfertig,

das sieht doch cool aus, da gucke ich mir in die Intuos rein,

was ich alles machen kann.

Sondern die fangen dann ihren eigenen Podcast-Client an.

Ja, so wie ich, das stimmt.

Ja, genau.

Vielleicht ist es ein bisschen zu enthusiastisch,

optimistisch

verblendet.

aber

wenn man das denn machen wollen

würde, dann ist es natürlich die Wahrscheinlichkeit,

dass jemand vorbeikommt und was macht, vielleicht viel höher,

wenn da schon sowas ist. Ja, ich würde sagen,

das macht tatsächlich dann Sinn, wenn das Projekt schon so ein

bisschen Drive aufgenommen hat,

ein paar Stars gesammelt hat und man dann

denkt so, hey, es wäre jetzt vielleicht cool, so ein paar

Nee, ich mache das vor allen Dingen

deswegen halt auch, um das zu üben, weil

wenn man es dann braucht, dann ist es ja

immer schlecht. Wenn man das dann erst lernt.

Genau. Man muss ja immer schon alles direkt perfekt

können. Nicht perfekt, aber so ein bisschen besser als wie man vergrattert.

Also perfekt.

Ja, es ist manchmal nicht so einfach.

Ja, also immer auf jeden Fall besser als alle.

Ja, ja, ich verstehe das.

Ah, ja.

Ja, das ist halt aber tatsächlich so eins der Probleme, die wir in unserer Gesellschaft

und unserer Kultur haben. Das sehen andere Leute aus anderen Ländern überhaupt nicht

so. Die verstehen das überhaupt nicht, warum wir da so völlig bescheuert sind.

Und denen ist das, also die können das wirklich nicht anbeziehen.

Ich finde das auch ein bisschen anstrengend immer.

und ich finde das auch nicht so produktiv

und es ist tatsächlich nicht so

Business-optimiert.

Ja, das mag sein.

Aber zu Glück muss ich auch nicht auf Business-Ziele

optimieren.

Ja, gut für dich, Jochen.

Ja, genau.

Ja, genau.

Ich wollte einfach mal ein bisschen

Übungen zu schreiben und

ja, das mache ich jetzt auch so ein bisschen.

Und tatsächlich, ich finde eigentlich

Podcast-Client ist, also habe ich schon erzählt, warum ich das

interessant finde oder was mich da so dran angesprungen hat.

Der Grund, warum ich das mache, ist, dass man das ja sowieso irgendwie braucht. Ich habe das Gefühl, ich muss es sowieso früher oder später irgendwann tun. Und der Grund, warum ich das tun muss, ist, weil da ja so viele schöne andere Dinge dranhängen, wie zum Beispiel, wenn du jetzt wissen möchtest, wie zum Beispiel ein Podcast aussieht in einem Podcast-Rosting.

Dann willst du den vielleicht importieren

Wie machst du das? Naja, du sagst halt, hier ist mein Feed

Importier doch mal

Feed importieren irgendwo her

und einen Client haben, der irgendwie sagt

Das ist fast das gleiche

Das ist fast das gleiche

Ja, fast

Und überhaupt

Vielleicht willst du einen Katalog haben

Da musst du auch die

Dinger parsen können

Podcast Client haben ist fast das gleiche

Ganz interessante Geschichte und dann wollte ich mal gucken

und Jochen unterhalten sich über die Programmiersprache Python

verwendet habe, ist Butt.

Das verwende ich auch immer noch. Ich finde das super.

Ja, so ist es. Das ist auch ganz gut.

Fast, Modern Unix.

Ja, aber bei mir

man kann es konfigurieren,

aber in der Default-Konfiguration macht es halt

irgendwie Zeilennummern davor. Ja, das kann man nicht mehr

copy und pasten, hast du recht. Das heißt, da kann man auch nicht mehr

pipen, wie man das mit Cut gewohnt ist. Und deswegen

muss man die Konfiguration anpassen. Das sind zwei

Environment Variables, die man testen muss.

Und dann muss man machen,

was man haben möchte.

Also eine für den Style und eine für die Teilnummern

und dann kann man das nach wie vor in einen Pipes einsetzen und kann das dann alias auch auf Cut und dann kann man Butt nehmen für Mitzeichnungen.

Ja, aber wie gesagt, wenn man

Rich nimmt, dann ist das halt, also Rich CLI und auf der Kommandozeile ist es dann einfach nur

Rich, dann muss man das eben nicht machen, sondern es funktioniert einfach so.

Und es kann auch ein bisschen mehr syntax-highlighting-Geschichten machen als Butt.

Also insofern, ja, kann man ja mal ausprobieren.

Also ich mag ja Rich auch, ich mache mit Rich auch

Konsolenanwendung teilweise.

Ja, gibt es jetzt auch.

Nein, das sage ich jetzt nicht.

Da müsst ihr jetzt warten

bis zum Schluss, dann picke ich nämlich das

stattdessen.

Und genau.

Da dachte ich, so kommen halt ein paar

Sachen zusammen, die das aus unterschiedlichen

Gesichtspunkten interessant machen. Deswegen habe ich damit mal

angefangen.

Ich habe, genau, also

eine der Geschichten von diesem Bootstrap-Ding

und Jungle-Crispy-Forms und so muss man irgendwie weg.

Ich habe jetzt auch, das habe ich relativ

aus anderen Gründen

und dann das jetzt nicht mehr in der privaten

Praxis viel mehr zu tun gehabt.

Es gibt auch irgendein, ich weiß nicht mehr,

ob das mit Crispyforms war oder sowas,

wo man einen Hook reinbauen kann

und dann halt die Forms mit Tailwind benutzen kann.

Ja, also ich würde sagen,

das wäre auch interessant, wenn da jemand

Empfehlungen zu hat.

Crispyform habe ich auch immer so verwendet. Ich habe es nie so genau

angeguckt, sondern immer nur so benutzt.

Und es hat ja einige ganz nette

Geschichten und es macht einige Dinge ja

einfacher. Und jetzt habe ich da so mal tief reingeguckt und ich muss sagen, das muss alles weg.

Das geht nicht. Das ist alles

ganz schrecklich. Also das ist halt irgendwie langsam.

Man kriegt es auch nicht schnell, weil es ist furchtbar. Und das ist

alles so. Also das ist, nee. Also ich

denke, man sollte das anders machen. Ich weiß jetzt auch noch nicht wie, aber man muss das irgendwie

anders machen. Das geht so nicht. Und das war mir nicht so klar vorher, als ich

noch nicht reingeguckt hat.

Das hätte ich auch schon nehmen.

Irgendwas mit Forms muss man sich nochmal ausdenken.

Ja, wobei,

das ist halt das Problem.

Ich meine,

wenn du das jetzt so machst,

dass du die CSS-Klassen in HTML setzt und so,

dann hast du halt beim Rendern ein Problem,

weil dann musst du das nämlich alles irgendwie setzen.

Wieso? Du machst ein Template für einen...

Ja, weil

das ist ja genau das Problem, das CrispyForms löst.

Du hast halt eine Form,

jetzt kommen die Formfehler zurück,

wie machst du das so, dass

jetzt deine Fehler ordentlich, dass da so ein roter

Klingel drumrum ist?

Ja, du benutzt den Default, den machst du zum Beispiel mit

Crispy Template, Crispy Table gibt es auch

und dann, also ich kann nicht sagen,

dass das auch langsam ist, weil das auch Crispy Form ist,

aber dann machst du halt einfach

in deinem Template, überschreibst dann halt den Default

und hast dann

einen schönen Style.

Du musst es ja in das HTML rausrendern, weil die Klassen müssen ja im HTML drin sein.

Das wird dann da reingeredert,

wenn du einfach deine Form erzeugst und die Form

gibt es im Flanko View.

Also wie passiert das denn zum Beispiel, wenn da halt die Fehler zurückgegeben werden?

Du hast jetzt eine Form, jetzt validiert das nicht, sondern das sind irgendwie Fehler.

Dann nimmt dir die Fehlerklasse und in der Fehlerklasse hängt ein HTML-Element mit dran.

Ja, aber das ist nicht einfach irgendwie eine Fehlerklasse.

Doch, das ist doch...

Da wird ganz kompliziertes Zeug gemacht.

Da werden diverse Klassen hinzugefügt, diverse Sachen geändert.

Und das musst du auch machen, sonst geht das nicht gut aus hinterher.

Ja, aber du kannst ja überschreiben, glaube ich.

Ich hatte aber irgendwie mal ein, zwei Sachen

customised, ging. Ja, man kann so ein bisschen

customisen, aber naja, okay, keine Ahnung.

Also wie gesagt, dieses Problem hast du,

wenn du das HTML verändern

musst, wenn du jetzt einen Fehler rennst.

Dann musst du das irgendwie machen, wie auch immer

du das machst, aber du musst es ja irgendwie tun.

Und das ist nicht so, dass da irgendwas in Django drin wäre, was dir

dabei hilft, sondern da musst du halt dann irgendwie

Crispy Forms nehmen oder irgendwas anderes, was das halt für dich

macht. Und das ist halt nicht so

ganz einfach. Während wenn du jetzt, sagen wir so,

und Jochen unterhalten sich über die Programmiersprache Python

und zahlst du das in einem CSS und fertig.

Das macht es dann halt

deutlich einfacher. Aber ich weiß es noch nicht.

Ich muss mal gucken. Ich habe keine Ahnung.

Ich werde mich damit mal beschäftigen.

Da muss man so ein Template wieder bauen für

HTMLX und Django.

Also eine Geschichte

ist halt, ich weiß nicht,

SQL Model, sagt ihr ja.

Es gab jetzt auch letztens eine Episode

zu irgendwie wieder auf

TalkPython2Me.

Und das versuche ich ja gerade zu entfernen.

Zum Beispiel aus

aus dem

Fast Deploy.

Und der Grund ist,

weshalb ich das versuche zu machen,

ist, dass ich

versuche, mal das so ein bisschen

umzuorganisieren.

Dass halt so ein bisschen Software-Architektur

reinkommt. Ich weiß, das ist auch nicht ohne Gittermann Sache.

Ich habe auch früher mal schon gedacht,

Software-Architektur.

Das schnürt mir schon, wenn ich das Wort ausspreche,

irgendwie die Krawatte, die Luft ab.

Als Architekt.

Ein feiner Herr.

Ja, geil. Aber

vielleicht gibt es Situationen, in denen das doch nicht so

verkehrt ist und ich wollte es einfach mal so ein bisschen

ausprobieren und deswegen mache ich das da jetzt

und genau,

da ist ja immer so...

Was ist denn Architektur, Softwarearchitektur überhaupt?

Naja, es ist im Wesentlichen

quasi die Beschreibung

für die Tätigkeit, die man halt

ausübt, wenn man

Software versucht zu modularisieren, also

so in Teile zu zerlegen, dass man nur noch

irgendwie, dass die

Gesamtkomplexität nur noch

dominiert wird von der Komplexität des kompliziertesten, komplexesten

Moduls und nicht mehr alles mit allem zusammenhängt.

Und die Art, was man macht, wenn man das jetzt tut und versucht, das klein zu hauen,

das nennt man Softwarearchitektur, sage ich jetzt mal so.

Das wäre jetzt meine aus der hohlen Hand Definition. Es gibt da Leute, die versucht haben,

das ernsthaft zu definieren, wie so Martin Fowler und so, die würden sowas sagen wie

Softwarearchitektur sind alle die

grundlegenden und schwer änderbaren Entscheidungen, die

ich weiß nicht, ob ich die Definition richtig zusammenkriege,

die Einfluss dann halt auf das Projekt haben und die dazu führen,

ob man jetzt irgendwie Dinge schneller ändern kann oder nicht. Kann man auch kritisieren,

es ist so wichtig, ob man Code hinterher ändern kann oder nicht,

was sind das denn eigentlich, wenn man weiß, dass es wichtig ist, dann hat man ja schon den Teil der

Softwarearchitektur irgendwie erledigt im Grunde, man weiß halt vor allem bei den Entscheidungen halt dummerweise

leider vorher meistens nie, ob die jetzt wichtig sind

oder nicht. Aber das ist halt

eine Definition. Ich glaube, ich habe die von,

die haben auch andere Leute so ähnlich

auch schon gebracht.

Mir gefällt

die, irgendwie, wie zerlegt man

eigentlich ein Programm in kleinere Teile

ein bisschen besser.

Aber, ja gut, ist halt

ein bisschen schmackser. Aber im Grunde irgendwie so,

man kann sich das auch vorstellen, ja, wie wenn man ein Haus

da Eisvektor hat, dann kann man auch für ein Software-Ding

Eisvektor haben. Also Microsoft

ist das für so Häuser breitstellen. Also

auf seinem eigenen.

Microservices wäre halt ein

Ding, wie man, also aber Architektur

bezieht sich jetzt nicht auf

den IT-Teil, nicht auf das System,

sondern

eher auf die Software. Also

du kannst natürlich auch, ich meine, das sind halt

eher so die Dinge, wo ich das Gefühl habe, das geht dann halt schief.

Wenn Leute

das Software-Problem,

weil sie es irgendwie nicht lösen können,

das sieht man übrigens ganz oft, also

mir begegnet das häufig und es ist

furchtbar.

meistens, also die Konsequenzen sind meistens

furchtbar,

dass Leute halt diese Modularisierungsding

in der Software nicht gebacken kriegen, aus welchen Gründen

auch immer, und dann

hingehen und das versuchen auf einer anderen Ebene

zu lösen. Also auf der Ebene zum Beispiel, was man

häufig sieht, ist, dass die Leute dann versuchen, das organisatorisch

zu lösen, oder dass Leute versuchen, es mit

IT-Geschichten zu lösen,

irgendwie, wir nehmen jetzt die Cloud, oder

dass Leute es mit Microservices

versuchen, und all diese

Ansätze sind eigentlich immer, das scheitert immer ganz schräg.

ganz spektakulär, weil

an dem grundsätzlichen Problem

ändert sich dadurch nichts und du hast dir das Leben

halt irgendwie gerade nochmal

in Größenordnung schwerer gemacht, dadurch, dass du jetzt

zum Beispiel...

Ein Park, ein Fuhrpark,

ein Zoo...

Ja, gerade Microservice gab es auch

letztens, habe ich auch letztens in einem Podcast

darüber gehört, es gibt

ein Buch, das irgendwie alle immer referenzieren, was

Microservice angeht

und der

sprach dann halt auch so drüber,

der hat das Buch geschrieben und meinte so, ich bin ein bisschen

unglücklich, ich gelte jetzt immer als der Experte für Microservices,

jetzt, weil ich dieses Buch geschrieben habe, na gut.

Und der meinte,

er macht halt viel Consulting irgendwie und

wird eigentlich immer dazu gerufen, wenn irgendwelche

Leute auf die Idee gekommen sind, wir müssen jetzt mal auf

Microsoft-Architektur umsteigen.

Und dann holt man sich halt irgendjemanden dazu, der dann

sagen soll, warum das irgendwie alles eine super Idee war.

Und dann sitzt er dann immer

und meint so, hm,

das ist vielleicht gar nicht so eine gute Idee in eurem Fall.

Und das

macht ihn halt nicht unbedingt beliebt, aber er versucht das dann irgendwie so diplomatisch zu verpacken.

Aber ganz oft ist es halt so, dass Leute das dann so probieren,

aber eigentlich sollte man vielleicht andersrum anfangen und eher Monolith nehmen

und dann halt, wenn man dann auf bestimmte Probleme stößt, die man anders nicht mehr lösen kann,

dann Microservice ist dann vielleicht eine Möglichkeit unter Umständen.

Aber damit anzufangen, ohne zu wissen, was man jetzt eigentlich machen möchte,

das ist vielleicht nicht so eine gute Idee.

und das ist eigentlich, also wenn man jetzt halt

vorher schon ein Problem mit der Modularisierung

hatte und dann auch noch

Microservices dazu nimmt, dann hast du halt hinterher

einen Distributed Ball of Mud sozusagen.

Also das Problem

an

Modularisierung

kann sein, dass man verschiedene Stellen hat, an denen man

Dinge pflegen muss?

Ne, Modularisierung ist eigentlich eine gute Sache.

Aber wenn nicht, du hast gerade

ein Beispiel gesagt, du hast gesagt,

das ist gut wenn man das hinkriegt das ist gut Wenn man es nicht hinkriegt ist doof aufzunehmen Also wenn du es nicht schaffst sozusagen Dinge voneinander zu trennen Wobei jetzt auch nicht Trennung beliebig super ist

Natürlich kann man das auch falsch machen, in dem Sinne, dass man das an den falschen Stellen trennt,

in der falschen Granulatität trennt. Das ist natürlich nicht schlecht.

Und wenn man jetzt sozusagen es aber gar nicht schafft, das zu trennen

und sagt, wir machen jetzt aber Microservices, um die Sachen, wo wir es falsch getrennt haben,

nochmal zu zementieren, indem wir es auf andere Rechner packen.

und in andere Repositories und so

und dazwischen halt jetzt

Schnittstellen haben, die wir schlecht ändern können und

die, wo wir Fehlerbehandlung machen müssen

und das ist alles ganz, ganz schrecklich, dann

ist das halt noch viel schlimmer als vorher.

Also wenn du vorher das Problem hattest, du hast es nur in deiner

in deinen Funktionsaufrufen

nicht geschafft, das ordentlich zu trennen

und jetzt hast du es halt irgendwie

diese Funktionsaufrufe verteilt,

aber du hast es

quasi nicht wirklich modularisiert,

sondern du hast ja Abhängigkeiten immer noch,

dann hast du danach

ein viel schwereres Problem als vorher.

Du hast es nur dann eine ganze Zeit

lang nicht mehr gemerkt, weil da warst

du damit beschäftigt, irgendwie Kubernetes

zu konfigurieren, so ein halbes Jahr oder so.

Und dann nach einem halben Jahr fällt dir auf,

das Problem ist eigentlich noch viel schlimmer als vorher.

Und das ist halt dann,

dann bist du in einer doofen Position, weil da

kommst du dann auch nicht mehr so leicht raus.

Und ja, das ist halt

genau, ja, das ist halt

ja, Architektur,

genau, also jedenfalls

Damit beschäftige ich mich halt auch gerade so ein bisschen.

Ich meine, da müsste man mal drüber reden, wenn ich da irgendwie mehr zu weiß.

Ich glaube, da müsste man auch eine eigene Folge zu machen.

Oder auch Microservice versus Modulit.

Wenn ihr das auskennt,

dann sagen wir uns Bescheid.

Hallo, ich heiße Martin.

Genau.

Was ich halt gerade versuche, ist halt mich mit diesem

Was macht man denn eigentlich so

üblicherweise, wenn man jetzt eine

Architektur, wenn man überhaupt so ein bisschen

Architektur haben möchte,

wie macht man das denn?

Und zum Beispiel, was ich, ein schönes

Zitat, was es halt in dem Buch, diesem

Software-Energischer-Patterns

was Python-Buch, das ich da so lese,

zu lese, gibt,

ist halt,

und ja, das fällt mir halt dazu,

dann auch allen,

wenn man sagt, ja, super,

ich kenne das, ganz viele Leute,

ah, super, Microsoft ist voll gut,

oder sonst wie, irgendwie,

ja,

das hatte mal, glaube ich, der Autor von

von Clojure

der Programmiersprache

Rick Hickey

hat das gesagt

und hatte so, ja

es gibt immer unter Ökonomen

den Witz, ja, so Ökonomen kennen

wie den Preis von allem, aber den Wert von nix

und für Softwareentwickler

kann man das halt auch anpassen und sagen, ja

Softwareentwickler, die kennen halt

irgendwie die Vorteile von

oder die Features,

aber sie kennen halt irgendwie

die Trade-offs und die Nachteile von Nix.

Und das ist halt,

das ist so ein bisschen, da ist was Wahres

dran und

zum Beispiel

eben, das ist da,

wir hatten ja letztes Mal diese

Fast-API-Episode oder so.

Also,

das ist so,

ich weiß nicht, würde

man, auch

wenn ich das so, auch bei

bei TalkPython-Termin oder so, wenn ich das höre. Ich höre immer so, ja, das ist alles voll gut und so.

Aber es gibt ja auch Nachteile, die das hat, wenn man das jetzt so macht.

Also wenn man jetzt zum Beispiel sagt, man nimmt jetzt FastAPI, nehmen wir mal ein paar Beispiele,

du nimmst halt FastAPI, SQL-Model und so und

alles funktioniert mehr oder weniger automagisch. Was ist der große

Nachteil an dieser Geschichte?

Erzähl. Tja, da würde ich sagen, eben, da bist du schon

Typischer Softwareentwickler, die meisten würden sagen, ja, das hat doch keinen Nachteil.

Es hat halt schon Nachteile und der Nachteil ist halt,

wenn du halt von SQL-Model erbst, dann kannst du das nie wieder ändern.

Wenn du jetzt auf die Idee kommst, wir machen das, oder du stellst halt fest,

du misst das, du hast viele kleine Sachen, die halt serialisiert werden müssen,

das ist halt zu langsam, das funktioniert irgendwie nicht.

Und das ginge besser, wenn ich das jetzt irgendwie mit einem Unpile machen würde oder keine Ahnung,

dann, das kannst du nicht mehr anpassen.

das ist halt einfach, dann hast du halt mehr oder weniger

verloren. Naja, du könntest ja schon

Export der Datenbank machen und Import von anderer Stelle

man muss dann so kurze Downtime kaufen und so

Conversion

dazwischen schreiten, also irgendwie geht das ja schon

Wenn da eine Business-Logik

da drin hängt

und du hast von SQL-Model geabt

oder von

Pidentic, irgendwie von den Base-Models, da kannst du

nicht mehr viel machen, das ist halt dann

das ist halt das Problem, du hast halt

oder sagen wir mal so, ich will gar nicht

auf Fast-API rumhacken oder so, also ich meine

dieser Ansatz ist ja durchaus verbreitet.

Bei allen Frameworks ist es halt so,

du erbst von irgendwas und dann

hast du halt viel mehr

Fähigkeiten und hast halt in kurzer Zeit

sozusagen viel geschafft, aber du kannst es

halt auch nicht mehr ändern. Wenn du das in Django machst, ist das

das gleiche Problem. Wenn du in Django

irgendwie erbst du ja von

Models.irgendwas.model und

hast da deine Fields und so.

Was ist denn jetzt, wenn das aus irgendwelchen Gründen nicht mehr gut

auf deine Anforderungen passt?

Da musst du halt umziehen.

Aber das geht quasi nicht. Endpunkt pro Endpunkt.

funktioniert nicht gut. Das kannst du praktisch nicht mehr ändern.

Also da würde ich sagen, der große Nachteil,

du kaufst dir eine Menge,

du kriegst halt viel Magie einfach so ganz schnell

und es funktioniert ganz viel.

Der große Nachteil, den du dir einkaufst,

ist, du kannst das nicht mehr ändern.

Du hast dich ganz eng

an dein Framework gekoppelt.

Das ist die engste Kopflung, die es überhaupt gibt von irgendwas zu erben.

Und

jetzt eben

sozusagen diese klassische

Software-Architektur würde halt sagen,

ja, Frameworks sind nicht deine Freunde, sei

vorsichtig, wenn du von irgendwie mehr erbst.

Das ist immer, du koppelst dich da ganz eng.

Also all diese Sachen von Sachen erben,

Sachen importieren, alles

vielleicht nicht so gut, weil das lässt sich hinterher alles

selber machen.

Das musst du ja nicht. Du könntest zum Beispiel stattdessen

eine Software-Architektur machen.

Ist halt die Frage.

Du meinst Kapseln dann?

Du kannst es halt

so machen, dass zum Beispiel dein

Kern, deine Applikation halt

von überhaupt nichts abhängen, von XR und auch nichts importiert.

Aber es braucht einen Händler für Speichern von Daten.

Ja, aber den kannst du reinreichen sozusagen.

Genau, aber das ist dann eine Dependency Injection, habe ich das jetzt richtig?

Ja, genau. Du würdest die Dependencies umdrehen.

Du würdest halt sagen, der Kern meiner Software basiert halt

oder hängt halt ab von anderen Sachen, sondern du würdest sagen, man dreht das halt um

und die anderen Sachen hängen halt von meiner Software ab.

und als

Mittel, um das zu erreichen, könnte man

Dependency Injection zum Beispiel verwenden,

aber das muss man ja auch nicht automatisch, also Dependency

Injection oder

Dependency Injection Frameworks,

da wird das ja quasi

so ein bisschen automatisiert.

Man kann das ja aber auch manuell

machen. Also manuell heißt das

eigentlich, du machst das so, dass du

hast halt dann

quasi Schnittstellen oder irgendwelche abstrakten

Interfaces, von denen du

halt, die du halt sagst, okay, das ist halt

das, was hier, so, da wird zum Beispiel

so eine

Datenbank,

ein Repository, ja, das muss jetzt,

sagt gar nicht, was das für eine Datenbank ist,

sondern wird halt reingereicht, ja, dass halt bestimmte

Methoden hat und dann

bestimmte Schnittstelle hat. Also quasi Abstract Base Class

mit Methoden zu

implementieren, die man dann

verwenden muss als Injection und die man dann,

wo dann klar ist, okay, das muss jetzt

so und so implementiert sein, egal wie du das löst, das ist mir

wurscht, aber Hauptsache, du stellst diese Interfaces für mich

bereit, die benutze ich dann einfach und

Input, Output sind vordefiniert. Und man dependet dann

eben auf diese abstrakte Schnittstelle

und nicht auf eine konkrete Implementation.

Das habe ich tatsächlich auch schon mal gemacht.

Ja, das ist ja schon

so richtig.

Kannst du mich jetzt Architekt nennen?

Ich glaube, das darfst du nicht wieder.

Das ist gar kein Problem. Hast du alles schon gesehen,

welche Leute sich Architekt benennen?

Das ist wohl jetzt auch kein geschützter Begriff.

Ja, Informatiker glaube ich auch nicht.

Ich glaube, du darfst dich nicht

Diplom-Informatiker nennen, aber

im Maticast.

Ja, ist auch wurscht.

Jedenfalls,

wenn du halt auf diese Abstraktionen

dependest und nicht auf irgendwas Konkretes,

dann kannst du halt das,

die konkrete Implementation dieser

Schnittstelle halt austauschen.

Wenn du ein Repository hast, das halt irgendwie SQL Alchemy

war, kannst du sagen, okay, ich nehme jetzt ein Django

Repository stattdessen

und dann merkt deine Applikation gar nicht,

dass das geändert wurde.

Der Nachteil ist halt irgendwie

Django OEM und so, das ist ja schon nett,

und du sparst halt viel Arbeit.

Du musst halt dann nochmal selber bauen, die ganzen Methoden,

die es da halt gibt quasi. Und dann halt quasi,

du musst einer die abstrakte Klasse bauen, die musst du dann

für deine Sache identifizieren.

Wenn du das mit dem Django-ORM nutzen willst, dann musst du quasi den Händler

dafür schreiben für deine abstrakte Klasse, die dann

den Django-ORM benutzt, damit die Methoden,

die du dir bereitstellen willst, auch dann darüber gehen.

Ja, also sagen wir so, du verlierst halt

einen Großteil der Gründe, warum man

jetzt... Der Convenience. Der Convenience,

den verlierst du tatsächlich, das ist halt so.

Dadurch, dass du halt Django

austauschbar machst oder FastAPI

austauschbar machst. Ich habe das

überlegt, zum Spaß könnte man eigentlich

noch einen Flask Entry Point

davor hängen, wenn ich damit

fertig sein sollte und das wäre praktisch

kein Problem, das zu machen. Ich könnte halt

Flask gegen FastAPI austauschen oder umgekehrt

oder Django, das wäre alles kein großes Problem,

aber man hat halt auch die ganzen Vorteile dann nicht mehr.

Das ist halt dein Nachteil.

Aber ja,

ich wollte es einfach mal ausprobieren, deswegen habe ich da so ein bisschen

mit angefangen und

ja,

Ja, aber man sollte sich halt, wenn man jetzt

ihm diesen Weg geht und sagt, ich nehme einfach ein Framework, dann ist alles schnell

Ich wusste, dass man das Software-Architektur nennt und so ein bisschen

Hochtraben überlegt

Ja, abstrakte Infrastructures bauen, damit man so ein bisschen

die Dependency-Insertion auslagern kann und damit man reduziert die Abhängigkeit

in seine eigenen Codes von anderen Dingen

und die einfach austauschen kann. Also dieses Pattern

der Dependency Injection in diesem Fall, mit diesem abstrakten