Transkript: CSS / Markdown / Microservices

Ja, hallo und herzlich willkommen bei einem Python-Podcast.

Heute Episode 40, Jochen im Jubiläum.

Oh ja, herzlich willkommen, Dominik.

Ja, 40.

Das ist ja schon viel älter als wir sind.

Ja, fast.

Ja, zumindest teilweise.

Ja, noch.

So.

Was wollen wir heute machen?

Wir haben erst überlegt, ob wir irgendwas über Ensibel erzählen wollen, aber das müssen wir wann anders, glaube ich, nachholen, weil wir niemanden gefunden haben, der sich mit Ensibel so richtig gut auskennt, den wir ja gerne als Gast gehabt hätten.

Wenn ihr also von Ensibel Ahnung habt und was erzählen wollt, dann sagt uns doch einfach mal Bescheid.

Das gilt

auch übrigens für alles andere Feedback, was wir uns schicken wollt, an hallo im heißenpodcast.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 benutzt tun oder jemanden nennen, die wir mal fragen sollen.

Wir haben zwar noch viele schöne Themen auf unsere Liste und so, aber wir lassen uns doch 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.

Ja, die können ja einfach ihr Thema bringen, auf das sie besonders Lust haben und dann gucken wir.

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

Ja, ja, es gibt ja so eine Burn Rate, wenn man so funktioniert.

Genau, und dann am Schluss ist ja keiner mehr übrig.

Ja, aber was machen wir denn dann heute?

Wir wollten einfach so ein bisschen mal wieder kunterbunt durcheinander reden, Talks 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 klar tun.

Meta, ja, Meta über was, ja.

Über Podcasts ist es nicht Meta, bei Python ist es nicht mehr.

Ich glaube, das eigentlich so Webdev-Meta, oder?

Also was man so alles benutzen kann an Tools

oder so.

Ja, ich bin gerade so machen.

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 Maschine Learning-Kram und so, aber hab auch mal viel gemacht, aber in letzter Zeit ist es irgendwie mehr Webentwicklung, obwohl das andere Ding ja auch gerade so halb, ich weiß nicht, woran das liegt.

Ich muss ja vielleicht irgendwie einfach mehr Machine Learning wieder machen.

Ich wollte gerade zeigen, ob wir einfach den Job wechseln jochen.

Ja, das kann natürlich auch sein.

Ja, ja, gut.

Vielleicht Webentwicklung ist eigentlich so ein bisschen Convenience Webentwicklung, wo man machen.

Das kann man mal so ein bisschen dazwischen schieben, aber Teilzeiten ist nicht

so schlimm.

Also Machine Learning auf Blockchain oder so.

Oh mein Gott.

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

Duo-Infernale.

Aber genau, vielleicht fangen wir einfach mit News an.

Okay, warte mal, ich war noch die Kapitelmarke.

News.

Oh.

So.

Dafür musste ich jetzt aber ziemlich strecken.

Ja.

Das müssen wir noch optimieren.

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 eigentlich sie haben wollte, irgendwie funktioniert das alles noch nicht so richtig.

Ja, im Make-Produkt wird eh eine Laberfolge.

Was ist denn da schon wieder kaputt?

Okay, ich stelle jetzt hier mal das Ding im Ultraschall auf Follow, dem Ding da.

Wir benutzen

übrigens Ultraschall zum Aufnehmen.

Ultraschall 5, sehr gut.

Ein Plugin auf Reaper.

Ja, genau.

Wie produziert man Podcasts oder das müssen wir auch nochmal irgendwann machen.

Das haben wir noch gar nicht, haben wir da schon mal gesagt, wie man Podcasts produziert.

Wie wir online produzieren vielleicht.

Also Kurzversion ist tatsächlich, wir nehmen das auf mit diesem Plugin für Reaper.

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

Nein, nein, nein.

Ja, aber in der Testversion, also Evaluation-Version gibt es.

Also erstmal zum Ausprobieren kostenlos.

Ich wollte jetzt sagen auch.

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

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

Ja, und Shownotes schreiben und so.

Das macht man auch so leider nicht automatisch, sondern muss man irgendwie von Ort.

Ja, aber Show Notes kann man ja einigermaßen gebrauchen, dann kann man nochmal nachschauen, was denn dafür für einen Quatsch irgendwann mal erzählt haben.

Vielleicht ist dann ein bisschen Show Notes drin, wenn das denn jemand aufgeschrieben hat.

Genau.

So, jetzt kann ich auch die News-Kapitelmarke nochmal verschieben.

Hier hat es kein schlechtes Gewissen haben, weil.

Jetzt haben wir aber auch wirklich ein bisschen Meta über Podcasts, ist doch schon mal etwas.

Aber das bestimmt auch bei anderen Podcasts gleich erzählen.

Ja, aber vielleicht.

Erstmal News, News, na gut.

Das ist ein bisschen Neues.

Also ganz schick, Taskgroups gibt es jetzt in gerade gemerkt worden für Python.

Okay, was ist Taskgroups?

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 Leute irgend bisschen depressiv gemacht hat oder keine Ahnung oder geärgert hat.

Ich weiß nicht, genau wie man es am besten.

Also zum Beispiel Trio ist eine Bibliothek, die sich halt mit diesen ganzen Problemen bestellt.

Es ist halt auch schwierig, ja, Trio.

Nathaniel Smith hat die hat die geschrieben, also es gibt ja es gibt ja diverse Implementationen mit diesem Async.

Ich habe jetzt ganz viel gehört, aber ich habe immer noch nicht genau verstanden, was denn das Problem dabei ist und warum.

Das Problem ist halt, also sagen wir mal so, wir befinden uns, was dieser 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 Goto oder so.

Das wird jetzt ein bisschen abstrakt.

Es ist ja so, als wäre jetzt nebenläufig ein zweiten Gedanken losgelaufen, der aber nicht mit dem anderen wieder zusammengekommen ist, weil ich die nicht einsammel konnte.

Ja, aber genau, also nachdem man strukturierte Programmierung, also mit Funktionen und so oder Prozeduren irgendwie eingeführt hatte, dann muss man sich auch erstmal sich umgewöhnen oder so, weil man das bisher mal 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 mach da irgendwie weiter.

Sondern man kennt das in logische Blöcke.

Die halt, 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.

Eine, nennt man das eine Closure?

Nö.

Enclosure ist eine innere Funktion, die halt Zugriff auf etwas hat, was ja, also du kannst zum Beispiel, wenn du eine Funktion innerfunktion hast und du gibst jetzt sozusagen die innere Funktion zurück, dann hat die ja noch Zugriff auf den Scope der Funktionen, 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 wrappen sozusagen die Funktionen, 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 meistens Decorator sind.

Oder ob die das alle schon wissen.

Da können wir mal eine, da können wir mal eine Episode zu machen, Dekoratoren, super Sache.

Eigentlich schon, ne?

Ja.

Ja, okay, dann machen wir da eigentlich eine Episode zu.

Haben wir schon mal wieder eine.

Man rappt dann quasi die Funktion und dann, da die ja aufgerufen wird und das Funktionsobjekt da durch die Gegend gereicht wird, muss man da halt Objekte oder Dinge reingeben können, rausgeben können und kann halt vorher, nachher draus machen.

Unter da irgendwelchen Kontext setzen, genau.

Und ja, also es ist nochmal was Komplizierteres.

Aber also Funktionen sind ja eigentlich relativ einfach, aber trotzdem, wenn man das halt nicht gewohnt ist, dann muss man das umstellen und dann ist die Frage, wie arbeitet man damit, was macht man jetzt eigentlich im Fehlerfall und so.

Und all diese Probleme haben wir jetzt nochmal so ein bisschen, weil wir jetzt uns irgendwie überlegen müssen, okay, wie, 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 Weltbenutzer von diesen Geschichten, hat man das eigentlich gar nicht so oft, aber kann man sich ungefähr verdeutlichen.

Also wenn man jetzt zum Beispiel, man hat halt so ein, also was man mit Async.io oft macht, ist sowas wie, hat zum Beispiel, also im einfachsten Fall, man halt eine Liste von URLs, die man abfragen möchte.

Und dann sagt man halt irgendwie Async.io oder man sagt halt Gether, den ganzen Kram und kriegt dann halt das alles zurück.

Was passiert denn mit.

Was macht denn das Gether jetzt, genau?

Das wartet, bis die alle einmal durch sind.

Alle awaiten.

Gether macht await eins nach dem anderen.

Und zwar in der Reihenfolge, wie die in der Liste drin steckt.

Oder das letzte

Reihenfolge gibt es so ja nicht mehr.

Naja, aber die laufen ja liebenläufig und eins ist ja zuerst fertig.

Ja.

Und eins zuletzt fertig.

Und Gether wartet, bis alle fertig sind.

Genau.

Das sozusagen, also man muss es halt noch awaiten, ne?

Aber das wartet, bis halt alle fertig sind.

Die Ergebnisse sammelt das auch?

Oder gibt es da Ergebnisse?

Ja, also man kann da durchaus auch, wenn das halt, wenn da halt Ergebnisse zurückkommen, jetzt weiß ich jetzt nicht genau, was mit all den anderen Dingern, wenn da jetzt unterschiedlich ist, also normalerweise hast du eine Liste von Sachen, wo 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.

Weil ich jetzt gar nicht so sicher, was dann passiert.

Wahrscheinlich kriegst du halt eine Liste der Frage.

Ja, okay, aussieht, keine Ahnung.

Aber das Problem ist halt eben, und das, was halt nicht so gut geht, wenn du jetzt sagst Async.io Gather und jetzt passieren aber mehrere Dinge.

Jetzt hast du zum Beispiel einmal einen Connection-Error irgendwie, wenn du eine URL holst und dann bei einem anderen Ding hast du aber irgendwie einen, weiß ich nicht, not authorized und bei dem anderen hast du dann irgendwie Authentication Error oder was auch immer, du hast halt so unterschiedliche Fehlertypen.

Du kannst jetzt aber im Interpreter kann, der kann immer nur eine Exception weiterreichen.

Was passiert denn jetzt?

Du kriegst die aber zu unterschiedlichen Zeitpunkten.

Wenn du jetzt sagst, try irgendwas, gather, was passiert denn jetzt, wenn du Accept sagst?

Ja, dann sollte die Exception, die zuerst rausfliegt, sollte rausfliegen.

Aber eigentlich sollte man die ja vorher catchen, oder?

Also innerhalb des Dekoro-Routine 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 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 zwar 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 in Tests passiert es auch häufig.

Während ich versucht habe, diese Exception zu werfen, ist halt das passiert oder keine Ahnung, also 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 halt ein ganzer Graph Baum 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 und Accept.

Und da der Code dafür ist jetzt irgendwie vor Woche oder so oder nicht, weiß ich nicht, ein paar Tagen, gemerged worden und alle so, juu.

Und das kommt in 311 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 leider auch irgendwie Structured Concurrency und der hatte dieses Konzept von Nurseries, die man da benutzen kann, um halt damit dann sauber umzugehen.

Das ist in der Asyn-Folge, glaube ich, schon mal erwähnt, was angehen.

Und das hat in der Asyn-Folge und ich weiß nicht, ob wir das wirklich, also ich glaube, das hat damals schon niemanden so wirklich gesagt.

Und wahrscheinlich ist das jetzt auch nicht anders.

Aber ich finde es interessant und es ist aber auch ein kompliziertes Thema.

Und naja, also sagen wir so, die Kurzfassung ist, es geht jetzt alles.

Also ab 311 wird es deutlich besser, es gibt da diverse Leute, zum Beispiel auch der Juri Selibanov.

Der mit EdgeQL und EdgeDB, der hat auf Twitter relativ enthusiastisch gesagt, so 3 Elf, 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, was das halt.

Ja, da muss er den Pep angucken, da steht das dran, wie man das dann, wie man dann damit umgeht, dass da jetzt so eine.

Du kannst halt auch, ich glaube, man kann das ganz normal, du kannst ganz akzeptieren.

Einmal nochmal kurz verstehen ja, wir haben jetzt relativ viel, also ich habe zwei verschiedene Exceptions, fangen wir mal mit zwei an, die gleichzeitig auftreten.

Also einmal, keine Ahnung, Autorisierung verweigert und einmal Connection abgebrochen.

In zwei verschiedene Spreads.

Was machen, du musst ja nicht Strets sein, kommst du.

Es gibt keine Spreads, also ist ja auch egal.

Die haben auf 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, wird das auch betrieben ist.

Naja, du kannst jetzt nach einem Zeitpunkt ordnen, du kannst es 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.

Also das, was das, und dann hast du halt quasi einen Baum.

Also eine Exception Group kann halt wieder unterschiedliche Exception Groups drunter haben, die dann wieder Exceptions runter 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-Dingsgeschichte baust, sowas wie zum Beispiel AsyncPG oder so, dann.

Also dann kann das durchaus passieren, dass dann dann halt dann dass du halt in solche Sachen reinläufst, wo du dann gerne irgendwie was gut, wo du zum Beispiel einfach nur einen ordentlichen Traceback werfen wollen würdest, wo man sehen kann, was passiert ist.

Weil wenn du das auf eins runterdampfen musst und dann rausschmeißen und sagst, Datenbank-Error, sagen wir mal so, gibt es eine Zahl, Zeile zurück, Datenbankfehler, dann ist das nicht sehr hilfreich.

Du musst halt, aber alle Sachen kannst du nicht angeben, weil du kriegst ja, du hast nur eine Exception.

Also weil die erste, die quasi dann geraced wird, dann die rausfliegt und die anderen gehen dann unter.

Das wäre das Problem sonst.

Genau, ja.

Ja, okay, und ich will halt quasi, dass sie durchgereicht werden.

Du willst die irgendwie behandeln können.

Ob du sie jetzt rausprintest oder irgendwie drauf reagierst oder so, ist ja nochmal eine andere Sache, aber du kannst sie jetzt handeln.

Also so wäre, das wäre quasi so, als müsste ich so eine Art Exception-Cache bauen und dann irgendwann alle Exceptions in diesen 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.

Also wie das damit umgehen.

Da gibt es unterschiedliche Ansätze wahrscheinlich, aber jetzt geht es halt so, dass es cool ist und sauber.

Ja, ansonsten hatten wir noch IPyth 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 noch ein bisschen zurückrudern.

Das hat die Leute irgendwie auch böse überrascht teilweise.

Das haben wir ja doch das mal noch gelobt.

Ja, ja, ja.

Aber im Prinzip ist es eigentlich schon richtig.

Und ja, es ist viel deprecated worden von Dingen, die man nicht mehr braucht und so.

Und ich glaube, ich habe es auch schon, es ist nur better, es ist noch nicht stable, aber ich habe es auch schon, also wenn man es einfach so installiert, macht halt keinen, man pinnt es nicht runter oder so, sondern man sagt einfach nur Pip Install iPython, 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.

Wir haben jetzt irgendwie super viele Episoden in letzter Zeit aufgenommen, wenn es gar nicht so viel passiert, weil gar nicht so viel Zeit vergangen ist.

Ja, okay.

Ich weiß nicht, hast du noch irgendwas oder haben wir noch irgendwie.

Ja, wir machen nochmal Werbung, diese Episode.

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

Also, diese Episode kommt wieder mit der freundlichen Unterstützung von NordVPN.

Ja, und schnapp dir den Exklusivdeal und ein Geschenk obendrauf zum NordVPN-Geburtstag.

Geh auf https, nordvpn.com slash Python Podcast und sichere dir den Wahnsinnsdeal jetzt auch komplett risikofrei mit 30 Tagen Geld zurückgarantie.

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 drauf verlassen, dass man dann weiter Netflix gucken kann, was man ja sonst irgendwie, manchmal hat man also Probleme zu Geoblocking 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.

Und dann warnt es die sichern, der jetzt auch komplett risikofrei mit der 30 Tage Geld zurückgarantiert.

Wunderbar.

Ja, 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 TSS-Framework benutzt denn du, Jochen?

Ja, irgendwie gar nicht.

Ihr habt vielleicht gesehen, Python-Podcast ist zu unserer Schande in Bootswap, weil das Einzige, was wir gemacht haben für Styling, ist Import TDN vom, also Bootswap vom CDN.

Ja, das weiß ich gar nicht mal.

Ich glaube, das mache ich tatsächlich nicht, aber das mache ich.

Oh Gott, das tatsächlich nicht schlecht.

Ja, 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.

Mache ich das wirklich?

Ne, ist das nicht so?

Ich meine nicht, aber ich gucke mal gerade in, ich mache hier gerade mal den das Netzwerk.

Wo ist denn?

Das steht doch immer unter Sources, ne?

Und dann steht da drin.

Oh ja, da sind diverse CDNs.

Code jQuerie.com, oh mein Gott.

Bootstrap CDN.

Oh nein.

Also, okay.

Ja, okay, das war mir gar nicht so klar, dass ich das mache.

Ja, ja, danke schön.

Dann ist mir das jetzt auch bewusst.

Ich dachte, ach, jetzt mal sowas mache ich aber nicht.

Aber doch, mache ich es schon.

Kacke.

Naja.

Ja, also Bootschap ist raus.

Also, 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-Bushware vom CDN und dann sieht alles irgendwie ein bisschen besser aus, als hätten wir es gar nicht gestylt.

Aber auch nicht viel besser, ehrlich gesagt.

Ja, vor allen Dingen ist es halt das, was in dem Jungwu Cookie Cutter-Template mit dabei war, deswegen habe ich das vor allem nichts.

Also du benutzt starke Cookie-Cutter von.

Jetzt, eigentlich seit einiger Zeit nicht mehr, aber ich habe es lange verwendet, ja.

Ja, also ich habe auch mal ausprobiert, das war nicht so ganz mein Ding.

Ja, also ich, ich, inzwischen würde ich auch sagen, also ich benutze inzwischen gerne irgendwie tatsächlich Start-Project oder halt auch das, das habe ich jetzt letztens wieder verwendet, das Project Template, weil man kann ja dem Start Project auch Project Templates mitgeben von Johannes.

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

Und Cookie Kata ist einfach, ist mir zu viel Zeug, dass 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, Farbapy.

Und dann klone ich die einfach.

Ja, kannst du halt auch machen, aber dann bleiben halt manchmal immer so Reste übrig.

Ja, aber das ist nicht viel.

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

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

Ja, also es ist halt, ja, es ist halt irgendwie, also ich bin da noch nicht bei.

Ja, andersrum ist, du fängst halt bei null an und dann musst du aus allen alten Projekten, wo du das so benutzt hast, erstmal reinkopieren.

Das geht auch nicht schneller.

Ja, aber genau, dafür sowas hast du ja normalerweise dann eben halt ein Template, damit du das nicht macht.

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 das ist irgendwie.

Ich hab inzwischen auch, also ich, ich am Anfang war, fand ich das tatsächlich hilfreich, weil es gibt ja so viele Settings in Django auch.

Es 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 schon lange 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 Ochs vom Berg.

Ja gut, aber wenn das jetzt von Figh Denny nimmt, also tatsächlich das Komplettprogramm mit Cookie-Cutter, das ist ja derselbe Typ, der auch Two Scoops auf Django

das Buch geschrieben hat oder die diversen Bücher, die es zu einem Thema gibt, die

Channel hatten und so.

Aber da ist so viel Zeug drin.

Da hast du so viel Zeug 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, das ist halt so.

Aber ich würde dich genau da, gerade 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 es gibt unterschiedliche, 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 Cookie-Cutter Django-Kooty-Cookie Cutter komplett weggebracht hat, ist halt, dass die halt irgendwann, das war auch nicht so, das war am Anfang 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 so stressig, das alles zu maintain.

Wir konsolidieren das jetzt auf Docker.

Und dann habe ich ja auch eine Zeit lang das mit Docker verwendet und jetzt würde ich sagen so, nee, ich will aber Docker gar nicht mehr.

Also weg damit.

Und ja, jetzt bringt es für mich sozusagen gar nicht mehr so viel, weil ja, das ist halt hauptsächlich Docker-Zeugs.

Ja.

Okay, aber wir sind quasi jetzt ja dahingekommen, also warum Bootstrap bei dir.

Genau, so ist das Bootstrap da irgendwie reingekommen.

Und ich weiß auch nicht, ob das noch da mit drin ist bei den 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, war mir auch nicht so klar, das ist ja irgendwie alles ziemlich riesig.

Und dann eben hat das noch so Dependencies auf jQuery und so.

Das sind ja alles Zeugs, was man heutzutage im Grunde nicht mehr wirklich haben will, braucht und so, aber es ist halt irgendwie dann alles immer noch mit dabei.

Ist noch

da drin, ja.

Ja, also von Foundation gibt es noch, das habe ich von Wannes mal.

Ja, von Foundation ist so quasi so ähnlich wie.

Ja, auch so, du musst halt eigentlich, du schreibst halt nichts, importierst halt einfach irgendwas vom CN oder kannst du es natürlich auch vom Lokal.

Und es sieht halt ein bisschen hübscher aus.

Man kann natürlich immer nass sein, wenn man will.

Dann gibt es noch Materialize und UI-Kit.

Und das sind alles immer so große klassenbasierte CSS-Sachen oder Post-CSS 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.

Enddesign.

Das kenne ich nicht.

Das ist auch total schräg.

Ja, ja, ja.

Endpunktdesign.

Das ist so, äh, das ist was Chinesisches.

Das ist auch so, das irgendwie, es gibt das hat mehr Stars auf GitHub als Django.

Und ist irgendwie in China verwenden, das Millionen Leute.

Aber hier kennt man das Ding gar nicht so sehr.

Ja, ist auch eigentlich.

Wahrscheinlich verwendet es deswegen, was gute Dokumentation auf Chinesisch hat, man weiß es nicht.

Ja, mag sein.

Dann gibt es noch Bulma.

Das benutzen zum Beispiel viel von den Vuejs-Leuten, also wenn man irgendwie jetzt auf Vemastery oder so Kurse macht.

Da gibt es so ein paar Leute, die Bulma machen, fand ich es, hat mich nicht so ehrlich begeistert.

Ist vielleicht eher so für.

Ja, aber es ist glaube ich die gleiche Kategorie wie eben.

Also das habe ich ja auch unter Utility First CSS-Frameworks genauso wie Tailwind.

Das ja auch.

Ja, genau, aber Tailwind würde ich sagen, so mache ich das.

Okay.

Ja, also finde ich sehr, sehr toll.

Ja, ich habe auch viel Gutes gehört und habe aber auch Leute schon schön gehört.

Also ich weiß es nicht.

Ja, also wir haben im Vorfeld jetzt kurz drüber gesprochen, du hast es gesagt, so oben Moment.

Also ich habe es zwar 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 einfach alles Unsinn, muss noch irgendwas anfangen.

Aber ich habe ja halt keine Ahnung davon.

Ich habe aber jetzt, jetzt reden wir da schon fünf Minuten drüber und ich habe ja auch eine Liste mir dann gemacht, weil ich dachte, irgendwie, vielleicht muss ich da mal irgendwie von 20 Dingern, die es hier irgendwie gibt, die ich mir alle mal angucken muss, ich denke so, ich habe noch überhaupt nicht angefangen, jetzt muss ich schon zwischen so vielen unterschiedlichen Sachen ausfüllen.

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

Oh mein Gott.

Und dann eben, genau, sowas macht.

Soll man jetzt das selber machen?

Soll man ein BAM machen?

Soll man irgendwie Utility First machen?

Bam.

Soll man ein Framework nehmen, soll man SAS nehmen, Lass nehmen, Post-CSS, irgendwie, was auch immer.

Ich weiß es doch alles nicht.

Und ich habe keine Ahnung.

Ja, ich würde ja tatsächlich Tablet nehmen.

Ja, gut, dann fange ich mal ein paar.

Aber du hast ja gesagt, das ist ja alles noch für Low-Budget.

Und ich bin ja eher, ich bin ja eher so, ich persönlich bin ja eher so der High-Budget-Typ.

High Roller, ja.

Ja.

Finde ich, ich muss sich da schon irgendwie so ein bisschen positionieren, ansonsten ist es da nicht, dass man da irgendwie.

Nicht mehr falsche Reise kommt.

Race to the Bottom irgendwie am falschen Ende rauskommt.

Das wäre nicht gut.

Ja.

Aber ich, genau, also ich weiß es halt nicht.

Und es gibt so andere Sachen, es gibt dann noch die ganzen Mini-Dinger.

Habe ich jetzt gesehen bei, wie heißt er noch?

Django high.

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

Da muss man immer CSS sein.

Also ich muss jetzt nochmal Tavent 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 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 Redundanzie auch nicht so schlimm.

Und ja, wenn du dann halt so ein Hot-Reloading-Wight noch nebenbei an hast, dann siehst du halt jede Änderung der Farbe, du schreibst halt Red als Klasse hin.

Und dann ist es rot.

Und dann schreibst du, Red Rex machst blau und es ist direkt blau.

Und das ist einfach, das ist so ein bisschen wie in den 90ern HTML-Koden.

Da musste man das ja auch alles noch direkt hineinschreiben.

Und ich mochte das.

Okay, ich habe das weder in den 90ern gemacht, noch jetzt, oder nur da dazwischen irgendwann, aber gut.

Naja, jetzt muss ich wohl doch irgendwie mal.

Ja, das musst du ja auf jeden Fall mal angucken.

Ja, wir haben ja auch eben noch über Winli kurz gesprochen, das ja auch noch gehabt.

Da gab es ja eine lustige.

Ne, ich hab, also über Tailwind, da gibt es eine neue Release, auch das hätten wir in die News packen können, ne?

Ja.

Siehst du mal.

Es gab eine Working Draft Episode letzte Woche oder sowas über Tailwind CSS 3, 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-File, hat es halt irgendwie immer die gleiche Größe an CSS ausgelegt.

Ja, man muss halt manuell purgen die CSS-Dinge, die man nicht haben wollte, die musste man dann wegpurgen, dass der File 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.

Also da dachte ich auch so, oh, das klingt aber gut.

Und dann eben hieß es ja auch, ja, das kommt aber von den Leuten von Winni oder so haben.

Ja, also Winnie hat ja Tailmann geklaut und dann Sachen so ein bisschen halt faster gemacht, vielleicht oder so, so ein bisschen so mehr auf Winnipere.

Und dann haben sich die Winnie-Leute beschädigt, dass sie sich, dass sie nicht gekreditet werden für diese Geschichten.

Und dann hat irgendjemand anders gemeint, so, ah, aber ihr habt das auch nur von mir wieder geklaut.

Keine Ahnung.

Sonst verflüßt das auf einmal so, als wären das jetzt irgendwelche Geheiminformationen.

Nö, sonst nicht, aber ich, keine Ahnung.

Naja gut, also noch.

Also ich mag tatsächlich auch die Betalsachen von Taylor ganz 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.

Ich glaube, es gibt auch dabei.

Es gibt ja auch so ein tolles Buch, irgendwie Refacturing UI oder so.

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

Vielleicht sollte ich das auch mal machen.

Vielleicht weiß ich da mehr, wie das mit den ganzen CSS.

Vielleicht sollte ich damit immer starten und irgendwie mal ein Buch lesen oder so.

Das könnte vielleicht hilfreich sein.

Ah, eine Geschichte, die tatsächlich interessanter aussieht als diese Miriade an irgendwie unterschiedlichen CSS-Arten, Frameworks, Minimal-Dingern, 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, ja, es gibt, das fehlt halt noch.

Also wenn man LGMX macht, das mache ich jetzt auch relativ viel.

Und das, da bin ich eigentlich super, super zufrieden mit.

Und ja, aber wie macht man das denn jetzt?

Weil da sind ja auch viele Animationsgeschichten oder so drin, die dann Sachen verschwinden, wenn man irgendwo draufklickt oder auftauchen und so Transition-Effekte und so.

Und ja, da haben sich überlegt, okay, dann brauchen wir eigentlich genau dafür eins, aber wir wollen vielleicht nicht so ein super, so ein 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 ein.

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

Ich muss mich damit immer auseinandersetzen.

Ich komme nicht mehr drum rum.

Ja, das erzählst du mir schon seit vier Jahren.

Seit Jahren.

Und dann habe ich doch immer wieder was anderes gefunden.

Ja.

Ja, es ist lässt sich aber, glaube ich, inzwischen echt nicht mehr vermeiden.

Ja, wie es ein bisschen.

Also deswegen empfehlen wir immer noch Tailwind.

Habe ich das schon gesagt?

Ja, ich bin ja auch nicht.

Ich bin ja kein Fan davon.

Ich weiß nicht genau warum.

Es war so ein bisschen, also ich konnte CSS sehr, sehr lange überhaupt nicht leiden.

Es war irgendwie mega hässlich.

Und dann Tailwind 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, dass es 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 seine 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 funktioniert.

Ja, sollte man schon, er sollte schon möglich sein, dass man seine Meinung aufwechseln kann.

Das ist glaube ich schon.

Ja, also wir werden, wir werden uns weiter Dinge angucken und dann sagen wir Bescheid, wenn wir irgendwie das perfekte gefunden haben.

Ansonsten, ja, ich meine, keine Ahnung, ich konnte 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 auch und hat so nicht mehr

zu tun.

Ja, ich habe ja diverse Projekte, ja.

Aber genau, momentan also eine Geschichte, die ganz interessant ist, HTMX, das beeinflusst halt so viele Sachen, weil das halt.

Mit HMX nachher den nächsten Trinkspieljuchen.

Wenn ich das sage muss.

Ja, stimmt schon.

Aber naja, also weil vieles, so gerade ich hatte, ich hatte mal irgendwann vor Jahren, also das ist zum Beispiel wieder eins von diesen Beispielen, so ein Bookmarking-Ding 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.

Und das letztens nochmal angefasst, wieder auf aktuellen Stand gebracht und da könnte man wahrscheinlich mit HGMX 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 denn da an?

Was nimmt man denn dann ein CSM?

Ja, genau, genau, genau.

Weil genau perfekt, genau dafür auch super geeignet.

Du hast ein Snippet, dass du per HMX rausrenderst und was schreibst du in deinen Snippet rein?

Ja, ja, genau.

Also das wäre natürlich nett.

Das sind halt so Sachen, die Telbed machen, ist halt, dass es, wenn es im Artimal drin steht, dann kann man es eben auch direkt mit raus.

Man muss halt nicht ein neues CSS mit ausliefern.

Genau, und du musst auch nicht jedes Mal in irgendein großes CSS, den 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 sein, dass du dann einfach doch Zinn-Button kleiner machst, obwohl das verboten ist im Style-Guide.

Ja, ich weiß, ich habe ehrlich gesagt keine Ahnung noch, wie man das alles wirklich macht, aber naja.

Ja, aber genau, das wäre, das wäre so, das war so einer der Gründe, warum ich da nochmal drüber nachgedacht habe.

Dann, äh, genau, aber auch sowas wie ja, diese, dafür würde ich gerne so eine Landingpage bauen, halt irgendwie Podcast-Hosting, Software as a Service-Geschichte.

Und da braucht man dann ja auch vielleicht ein bisschen mehr Design-Wumms und dann ist Bootstrap vielleicht irgendwie nicht das Richtige.

Also was wir da machen, ist Designer fragen.

Ja.

Dann machen die uns einen Entwurf, Design.

Und dann machen wir das in Tabeln.

Ah, okay.

Ja.

Ja, für irgendwie sowas, ne?

Ja.

Da helfe ich dir gerne bei.

Was machst du noch?

Du hast noch ein paar Sachen entdeckt, so ein paar Picks fast, ja, die.

Ja, aber genau, kann man auch einfach mal raushauen.

Da 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 enhancen, um sowas wie Diagramme.

Ja, genau.

Und das kann halt auch diese Diagramme, die Arten von Diagrammen, die man halt.

Also rendern.

Also das, was ihr von Draw.io vielleicht kennt, so ein bisschen oder so.

Wenn ihr so, ich weiß nicht, ob das in der Komplexität gerät, aber richtig coole Sachen, die man echt gut darstellen kann, ERM-Diagramme, Flowcharts, sowas.

Einfach als Markdown schreiben, so ein bisschen runterschreiben und dann könnt ihr das auch direkt rendern lassen.

Auch von sowas wie GitHub.

Ja, also ER-Diagramm habe ich oft irgendwie, da gab es so ein Plugin für, ich weiß nicht gar nicht, wie das hieß.

Auch in Django konnte man das irgendwie mit einbinden und dann hat das halt als Management-Command und hat das halt irgendwie ein ER-Diagramm rausgerendert.

Aber das Problem ist halt, die sind halt wenig konfigurierbar und wenn das halt groß wird, dann ist es halt irgendwie sieht man nichts mehr.

Und wenn das klein ist, dann hätte man ja mehr Informationen nicht.

Du meinst Graphis.

Und das hat mit Graphis oder Dot irgendwie hat das das dann gerendert, aber das ist alles nicht so.

Also da ist.

Ja gut, also für

das ERM-Diagramm rausrennen lassen aus den Models, ist das natürlich schon nett.

Also wir reden ja gerade über Mermade, dass das glaube ich nicht macht.

Nee, da machst du es von Hand, aber du hast 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 exotique ich halt einfach aus meinem Dangemodel kurz das EM.

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.

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

Und ein automatisch generiertes Ding in der Dokumentation ist halt irgendwie nicht so gut.

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 brauche ich ja keine Arbeitszeit reinstecken.

Wenn doch, dann sollte man es auch nicht machen.

Aber das ist immer ein bisschen die Frage, 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 mal gefragt, nehme ich ein 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, aber 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 auf dem Hintergrund funktioniert das aber nicht.

Halt diese ganzen Probleme.

Und das ist man halt alles los, wenn man das mit Mermaid macht.

Ja, also vor allem, das ist halt, wie gesagt, Maßstab.

Und ihr könnt auch sowas machen wie verschiedene Projekte, wie lange wollt ihr denn schedulen und dann nebeneinander.

Das finde ich echt sehr geil.

Also ich muss mir das unbedingt angucken, weil ich halt diese Tasks, die halt hintereinander kommen, mit wie lange brauchen die denn quasi so ein Agent oder sowas, wer 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 ja jetzt auch Empadox mir dann angeguckt und damit geht das halt auch.

Schmal gibt es ein Plugin.

Genau, Static Fate Rendering 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.

Notebooks?

Klar.

Aber sagen wir 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 ist halt, 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, dass das ist immer noch das, was am häufigsten verwendet wird.

Also, wenn man irgendwie Dokumentation von Projekten anguckt, das ist meistens Restructured Checks.

Aber ich habe es auch jetzt öfter mal Restructure-Tech mit Pfhinx oder so, ne?

Ja.

Versucht, aber.

Ich verstehe, wo das Problem ist.

Also es fliegt dann keiner mehr.

Also Markdown kann man irgendwie besser.

Ich weiß nicht, Restructure Checks wird es nicht schaffen.

Keine Ahnung, aber.

Bin ich mir so nicht sicher.

Also Markdown kann man so super viele Anlechungsfälle haben.

Man kann das halt einfach sein GitHub hochladen, das ist direkt gerendert.

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

Ich glaube, der ist leider, der war zwischendurch 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 brauchten, hey, schreib doch Typora, dann hatten die Markdown-Files voll toll.

Und die haben es gar nicht gemerkt, weil das so ein Wolf Whisky-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 es möchtest und dann kannst du so ein bisschen sehen, woran du arbeitest oder wie die Team untereinander verknüpft sind.

Die Links können machen.

Kennst du das Zettelkasten-Prinzip?

Luhmann ist das irgendwie, ne?

Ich weiß nicht genau, wie heißt.

Zettelkasten habe ich.

Ach, jetzt können wir es nicht erklären, jetzt müssten wir hier vorliegen.

Hier haben.

Doch, ich glaube, ich glaube.

Also du kannst auf jeden Fall Sachen da richtig einsortieren und hast die 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, auch Y unterstützt auch das, deine Ablage an dieser Methoden.

Mein Notiz-Block, Simple Note, ich muss nur nicht sagen, jetzt auch Markdown-Renderable und so.

Ja, also es sind ganz so viele Kleinigkeiten, die in diese Markdown-Welt reinspielen und diese Schlimmste sind alle interchangeable und das ist.

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 drauf guckt.

Ja.

Ja, ja, es läuft momentan alles so ein bisschen auf Markdown hinaus.

Mal schauen.

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

Da ist auch irgendwie Standardintegration, äh, standardmäßig die Integration an.

Das heißt, wenn man das einfach so reinschreibt, dann hat man das halt auch in Issues oder halt in irgendwie Markdown, was halt auch von GitHub gerendert wird.

Ja, überhaupt, aber das ganze Dokumentationsthema ist ja auch so.

In letzter Zeit habe ich nicht, also gerade

schon ein paar Tickets.

Genau, ein bisschen mit MacDocs beschäftigt, aber halt auch überhaupt mit diesem Ding, dass man das halt vielleicht mal tun sollte, weil, also Ansicht dazu, bisher war ja eigentlich immer so Dokumentation, ah ne, lieber nicht.

Ist ein bisschen zweifelhaft vielleicht und inzwischen denke ich mir so, na, 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 ist cool, das finde ich schwierig.

Also bei mir steht auch in den meisten Commits nur Schrott drin wie Fixed Something oder Fixed Final oder Fixed Again oder Typo oder 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, genau.

Wenn du das halt in einem Pull-Request ziehst.

Ja, aber das mache ich zum Beispiel.

Ja.

Ja, das würde man, den Pull-Request würde man machen.

Das ist bei mir relativ egal, wenn ich der Einzige bin, der auf so einem Branch-Ack hat, dann ist das völlig wurscht.

Ja, 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 das sehr sinnvoll, dass man gute Commit-Messages hat, wo auch was passiert und nicht nur zwei Leerzeichen gemittelt werden.

Dann müsste man auf jeden Fall seine Committees alles squashen und die ordentlich machen und so.

Aber also Commit-Messages ist jetzt bei mir so, da die gehen eigentlich, finde ich.

Die sind gar nicht so schlimm.

Alle sind auch ganz okay.

Ich habe mir mal über die Zeit mich mit euch unterhalten.

Das ist auch schon ein paar Jährchen her, glaube ich.

Und zwar, ob man die in Präsence oder in der Vergangenheitsform formuliert.

Ja, weiß ich ja auch gar nicht mehr.

Das Ergebnis war Präsenz wurde bevorzugt.

Präsence, ja, kann sein.

Ich weiß jetzt gar nicht, was ich meine, aber bei mir wird es nicht so gut.

Dieser Commit fixt dies und jenes, anstatt dieser Commit hat das und 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?

Also wann schreibt man quasi sein Ja.

Die Fixliste, also das ist dann Plugs und Features.

Wenn du eine Release machst.

Also die, ja, aber auf Semantic Virgining auf welcher auf meiner.

Semantic Virgining ist halt schon eine Sache.

Braucht man das?

Nein?

Warum nicht?

Naja, weil es ja auch nicht wirklich hilft.

Also es ist gut, auch da gibt es eine Menge Leute, die mittlerweile halt irgendwie einfach fortlaufende Geschichten.

Also 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 Patchvision.

Wenn man jetzt quasi ein paar neue Features eingebaut hat, würde ich sagen, schon Minor nach oben.

Machen wir einfach Minor einem hoch.

Neue Features, Minor.

Ja, also genau.

Und Major ist Breaking Change, also es geht irgendwas nicht mehr mit früher, dann ist 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 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 ja, auch Daten-Datum zum Beispiel dazu zu schreiben und dann halt noch die, kann man sich auch die Artikel mal im Detail angucken.

Ja, sei ja, stimmt.

Idealerweise sollte da die User-Story beschrieben sein, die gefixt wurde oder die für

dazu gekommen ist.

Das Spiel ist auch nicht gut.

Es sollte so sein, dass...

Das kann man schreiben.

Ja, gut, vielleicht ein Satz, okay, das ist okay, aber es sollte halt nicht irgendwie, genau.

Man kann ja durchaus die Issues und so reinschreiben.

Nein, aber der Titel vielleicht.

Also der User kann sich jetzt auf unserem Backend einloggen.

Oder sowas wie der User kann jetzt den Filter so bedienen, dass er alle möglich noch ist.

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

Das sollte man sich vielleicht auch überlegen.

In Devs.

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

Also ich würde sagen, aus einer technischen Perspektive sind ja User-Stories doch eigentlich komplett unentgleichbar.

Aber das wäre ja die technisch Formulierung von, du kannst jetzt in diesem Formular das und das die Auswahl verändern.

Technisch würde ich reinschreiben, was tatsächlich passiert ist, was man geändert hat.

Oder so Mittel-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 mit dem, 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.

Nee.

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, vielleicht, weil tatsächlich ja das Feature, das so man baut, vielleicht das ist, was man dann umsetzt.

Und wie man das, also das würde ich jetzt in so ein Release-Log reintreiben, welches Feature jetzt umgesetzt ist.

Ja, wie gesagt, aber ich glaube, es würde sich, würde wahrscheinlich schon viel helfen, wenn man sich überlegt, an wen richtet sich das eigentlich, wer soll das lesen.

Manager lesen oder Nutzer lesen oder die Devs lesen.

Und zum Beispiel ein Ding, das mich jetzt gerade interessiert, deswegen beschäftigt mich damit auch so ein bisschen, eben wenn man jetzt Entwicklung skalieren möchte, dann ist es vielleicht gar nicht so schlecht.

Also zum Beispiel eben auch andere Artikel, ich hatte es jetzt gar nicht mehr wie der Titel von dem war, dass Ivan Wilson geschrieben hat.

Also, ja, also er schreibt immer, seit einiger Zeit immer 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.

Auch.

Und zwar nicht nur.

Was ich ganz gerne mache, ist, das muss man halt immer ein bisschen einstellen, ist To-Do-Kommentare im Code.

Ja.

Aber die mit GitHub Post-Assessing, dass ich halt einen Hook habe, dass er halt automatisch aus meinen To-Dos im Code-Issues erstellt, auf GitHub und die automatisch wieder zumacht, wenn das To-Do da verschwindet und dass sie die automatisch auch nummeriert und das dann halt auch in einem Commit mit ergänzt.

Das heißt, er schreibt dann quasi an der 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 fliegen, sondern du kannst halt einfach im Code das dann bereinigen und dann ist er halt geschlossen und sowas.

Und das finde ich.

Ja, wenn

du eine Stelle hast an einem Code, wurde das hin, aber es gibt ja auch viele Dinge, die kannst du ja nicht an einer Stelle festmachen.

Aber gut, ja, ja, wie man es macht, ist ja letztlich ganz.

Du könntest 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 Issu auch super machen.

GitHub macht das ja gute.

Also es hätte nicht niemand daran, noch extra Issues aufzumachen, wollte ich

damit sagen.

Ja, ja, nee, klar.

Also ich weiß gar nicht, also wie man es jetzt macht, das kann man halt machen, wie man will.

Aber nee, was ich daran interessant fand, ist halt, also einmal sagt er halt irgendwie, aber er halt, was er, warum er das macht, ist halt, dass er einen Punkt haben möchte, sozusagen, an dem, an dem alles andere hängt und GitHub macht das halt automatisch für ihn, das alles zusammenzuführen, sozusagen, 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 an Änderungen an Dokumentation, Tests, 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 denn ü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 eine Issue auf und schreibt 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.

Und so anfängt nachzudenken, ist ja manchmal so ein bisschen, ist ja 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, äh, ganz nett.

Vor allen Dingen, ich habe das jetzt zum Beispiel für einen Ding, ich habe so einen Podcast-Client geschrieben.

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

Schreibt für diesen Ding Jagni.

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

Ja, Jagny könnte sein.

Oder halt auch einfach so Standard-Jack-Shaving, könnte auch gut sein.

Ja, eben, ja, ja.

Ich habe jetzt vielleicht nochmal eine Abschweife Richtung unternehmen.

Aber genau, und da habe ich mir dann gedacht, okay, das war dann halt auch das Richtige.

Das sind Issues, mache ich jetzt vielleicht mal auch mal so.

Klicke einfach schon mal ein paar Issues an, weil jemand vorbeikommt und da drauf guckt, dann kann er das vielleicht einfach so machen, einfach damit Leute halt einen Ansatzpunkt haben.

Weil 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 sagen sollst.

Die meisten Leute, die gehen ja nicht hin und gucken, oh, das gibt es denn schon für GitHubs für coole Podcast-Clients, oh, der ist auch total unfähig, das sieht doch cool aus, dann gucke ich mal in die Issues rein, was ich alles machen kann.

Nein.

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 und so ein paar Stars gesammelt hat und man dann denkt, so hey, es wäre jetzt vielleicht cool, so ein paar.

Nee, ich mach das vor allen Dingen deswegen halt, um das zu üben, weil wenn man es dann braucht, dann ist 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 vielleicht gerade vielleicht.

Ja, das 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, in 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, äh, die können das wirklich nicht nachvollziehen.

Ich finde das auch ein bisschen anstrengend immer.

Und die finden das auch nicht so produktiv.

Und es ist tatsächlich nicht so business optimiert.

Ja, das mag sein.

Aber naja.

Aber zum Glück muss ich auch nicht auf Business-Ziele optimieren.

Ja, gut für dich, Jochen.

Ja, genau.

Ja, ich, genau, ich wollte einfach mal so ein bisschen über Issues schreiben und ja, das mache ich jetzt auch so ein bisschen.

Und ich habe einen kleinen, und ich 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 man das irgendwie tun muss, ist, oder ich das Gefühl habe, dass ich das tun muss, ist, weil da ja so viele schöne andere Dinge dran hängen, wie zum Beispiel, wenn du jetzt irgendwie Aussehen wissen möchtest, wie zum Beispiel ein Podcast aussieht in einem Podcast-Hosting, 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.

Also.

Und überhaupt, ja, vielleicht willst du einen Katalog haben, vielleicht willst du irgendwie, da brauchst du, musst du auch die Dinger parsen können.

Feeds parsen können, Podcast-Client haben, ist fast das gleiche.

Ganz interessante Geschichte und dann wollte ich mal gucken, wie funktioniert eigentlich diese Feedparser-Library so, was muss man dafür eigentlich alles machen.

Ja, dann habe ich das irgendwie gestartet.

Und ich dachte, ach, Rich und so, das ist auch voll cool.

Ja, Rich und ich ja tatsächlich, habe ich ja schon ein paar Mal gepickt.

Ja.

Rich gibt es die Clea.

Rich Clee.

CLI.

Genau, das wollte ich eigentlich gleich nochmal picken, aber können wir auch jetzt machen.

Ist mir egal.

Das wäre dann Pick gewesen, okay.

Entschuldigung.

Statt Bud, hast du gesagt, nimmst du Rich CLI, weil es so wunderschön Dokumente darstellen und Markdown-Rändern und Tabellen, CSU.

Genau, also das, was ich bisher eigentlich immer verwendet habe, ist Bud.

Das verwende ich auch immer noch.

Ich finde

das super.

Ja, so ist.

Ist auch ganz gut.

Pars, Modern Unix.

Ja.

Aber beim Konfigurierbar.

Man kann es konfigurieren, aber in der Default-Konfiguration macht es halt irgendwelche Zeilennummern davor.

Ja, das kann man nicht mehr Copy and Pasten, hast du recht.

Das heißt, das kann man auch nicht mehr pipen, wie man das mit Cut gewohnt ist.

Und deswegen muss man die Konfiguration anpassen.

Das sind zwei Environment-Variablen, die man setzen muss.

Und dann muss man machen, wenn man das so 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 Aldiassen auch auf Cut und dann kann man Butt nehmen für mit Teilnummern.

Ja, aber wie gesagt, wenn man Rich nimmt, dann ist das halt, also Rich CLI und auf der Kommanderzahl ist es dann einfach nur Rich als 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 habe gewinnen.

Das kann es auch natürlich.

Also ich mag ja Rich auch, ich mache mit Rich auch Konsolenanwendungen teilweise.

Ja, gibt es jetzt auch, naja, nein, nein, das sag ich jetzt nicht.

Da müsst ihr jetzt warten bis zum Schluss, dann picke ich nämlich das, nämlich stattdessen.

Na gut.

Und genau, ja, und da dachte ich ja so, kommen halt ein paar Sachen zusammen, die das aus unterschiedlichen Gesichtspunkten interessant machen, deswegen habe ich jemandem angefangen.

Ich hab, genau, also einige der Geschichten, also von diesem Bootstrap-Ding und Django Crispy Forms und so muss man irgendwie weg.

Ich hab jetzt auch, das habe ich, das habe ich relativ aus anderen Gründen und dann das jetzt nicht meine privaten Projekte so viel mit zu tun gehabt.

Es gibt

auch irgendeinen, ich weiß nicht mehr, ob das mit Crispy-Forms war oder sowas, wo man einen Hook reinbauen kann und dann halt die Forms mit Tablement benutzen kann.

Ja, also ich würde sagen, das war auch interessant, wenn da jemand eine Empfehlung zu hat, wie man das, also ich hab mir jetzt Crispy-Form habe ich auch mal so verwendet, ich habe es nie so genau angeguckt, sondern immer nur so benutzt.

Und es ist ja auch, es hat ja einige ganz nette Geschichten und es macht einige Dinge ja einfacher.

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

Das muss alles, 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 da noch nichts reingeguckt habe.

Dachte ich da, komm schon nehmen, ne?

Aber jetzt, ja, okay.

Irgendwas mit Forms muss man sich nochmal ausdenken, okay.

Ja, wobei, wenn man halt irgendwie, da hast du jetzt wieder, das ist halt das Problem.

Ich meine, wenn du das jetzt so machst, wie mit dass du die CSS-Klassen in eine HTML setzt und so, dann hast du halt beim Rendern ein Problem, weil dann musst du das nämlich alles irgendwie setzen unter Umständen.

Wieso, du machst ein Template für einen

Ja, weil also das ist ja genau das Problem, dass das CRISPR-Forms löst.

Du hast halt eine Form, jetzt kommen die Formen Fehler zurück.

Wie machst du das so, dass jetzt deine Fehler ordentlich gesetzt, dass halt so ein roter Kringel drumrum ist?

Ja, du nutzt R den Default und den machst du also zum Beispiel mit CRISPR-Template, CRISPR-Table gibt es auch.

Und dann, ähm, also kann sein, dass das auch langsam ist, ja, weil das dann auch Crispy Forms ist.

Aber dann machst du halt einfach in dein Template, überschreibst dann halt den Default und hast dann deinen schönen Style.

Nein, aber du musst es ja in das HTML rausrendern, weil die Klassen müssen ja im HTML drinnen.

Das wird dann da reingerendert.

Wenn du einfach deine Form erzeugst und die Form gibt es nicht mehr so.

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 da sind irgendwie Fehler.

Dann nimmt die Fehlerklasse und im Fehlerklasse hängt ein HTML-Element mit dran.

Ja, aber das ist ja aber das.

Das ist nicht einfach irgendwie eine Fehlerklasse.

Doch, das ist nicht, das ist.

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 nicht, ja, du kannst ja beschreiben, glaube ich, anders.

Ich hatte irgendwie mal ein zwei Sachen customized, das ging.

Ja, man kann so ein bisschen customizen, aber naja, okay, keine Ahnung.

Also wie gesagt, also dieses Problem hast du, wenn du das halt, wenn du das HTML verändern möchte, äh, verändern musst, wenn du jetzt den Fehler änderst, dann musst du das irgendwie machen, wie auch immer du 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 es halt für dich macht.

Und das ist halt nicht so ganz einfach.

Während wenn du jetzt, sagen wir so, du hast jetzt getrenntes CSS, ja, dann und du hast halt da definiert, wie dein Scheiß, wie dein ganzer Kram halt so aussieht.

Und da setzt du halt dann, sagst du jetzt hier, Fehler, rennerst aber ganz normales, semantisches HTML raus.

Ohne dass, dann hast du sozusagen in deiner Applikationslogik irgendwie kein Problem damit, dass du da irgendwie komische Dinge, äh, Klassen auf HTML-Geschichten setzen musst und so, sondern dann sagst du halt irgendwie nur, das ist mein Standard, ich weiß nicht, was von Django dann zurückkommt, was da für eine Klasse gesetzt wird oder wahrscheinlich irgendwas.

Und dann zahlst du das in einem CSS und fertig.

Das macht es dann halt deutlich einfacher, ne?

Also, aber ich weiß es nicht, muss mal gucken.

Ich hab keine Ahnung.

Damit man beschäftigen.

Dann muss man so ein Template wiederbauen für HTMX und Django dann.

Also, eine Geschichte, die ist halt, ich weiß nicht, SQL-Model, sagt er ja vielleicht auch.

Es gab jetzt auch letztens eine Episode zu irgendwie wieder auf Talk Python to me.

Und das versuche ich ja gerade zu entfernen, zum Beispiel aus dem Fast Deploy.

Und der Grund ist, weshalb ich das versuche zu machen, ist ja, ist, dass ich versuche, mal das so ein bisschen umzuorganisieren.

Dass halt so ein bisschen Software-Architektur hinkommt.

Ich weiß, das ist auch nicht unbedingt jedermann-Sache, ist auch, ich habe auch früher mal schon gedacht, so Software-Achiturguiert, das ist so ein bisschen.

Das verschnürt mir schon, wenn ich das Wort ausspreche, irgendwie die Krawatte die Luft ab, irgendwie so.

Architekt, feiner Herr.

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, Software-Architektur überhaupt?

Naja, es ist im Wesentlichen quasi die Beschreibung für die Tätigkeit, die man halt ausübt, wenn man Software versucht so 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 komplexesten Moduls und nicht mehr alles mit allem zusammenhängt.

Und die Art, wie man, was man macht, wenn man das jetzt tut und versucht, das klein zu hauen, das nennt man halt Software-Architektur, sag ich jetzt mal so.

Also Software-Engineering.

Es gibt da, das wäre jetzt meine außer hohlen Hand Definition.

Es gibt da Leute, die versucht haben, das ernsthafter 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, 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 Geschmackssache.

Aber im Grunde irgendwie so, man kann sich das auch vorstellen, ja, wie wenn man ein Haus da Architektur hat, dann kann man auch für ein Software-Ding Architektur haben.

Also Microservices für so Häuserbreitstellen, also jedes Thema auf dem 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, also ich meine, das sind halt eher so die Dinge, wo ich das Gefühl habe, das geht dann halt schief.

Wenn Leute das Softwareproblem, 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, es organisatorisch zu lösen oder dass Leute versuchen, es mit IT-Geschichten zu lösen, ja, 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 spektakulär.

Viel anders.

An dem grundsätzlichen Problem ändert sich dadurch nichts und du hast dir das Leben halt irgendwie gerade nochmal irgendwie mit Größenordnungen schwerer gemacht, dadurch, dass du jetzt zum Beispiel.

Andere Service, ganz viele Park, ein Zufuhrpark von einem Zoo.

Ja, ja, ja.

Gerade Microservice gab es auch letztens, habe ich auch letztens eine Podcast-Episode darüber gehört, mit dem es gibt ein Buch, das irgendwie alle immer referenzieren, was Microservices 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 geld jetzt immer als Experte für Microservices, 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 Microservice-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, ist vielleicht gar nicht so eine gute Idee in eurem Fall.

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

Aber er meinte so, ja, das ist 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 ein Distributed Ball of Mutt sozusagen.

Also das Problem schlimmer an Modularisierung kann sein, dass man verschiedene Stellen hat, an denen man Dinge fliegen muss.

Ne, Modularisierung ist eigentlich eine gute Sache.

Aber wenn nicht, du hast gerade ein Gebenbeispiel gesagt, du hast gesagt, wenn man Probleme da gibt.

Das ist gut.

Also wenn man das hinkriegt, ist es gut.

Wenn man es nicht hinkriegt, ist doof.

Also wenn du es nicht schaffst, sozusagen Modular.

Dinge voneinander zu trennen.

Ja, wobei jetzt auch nicht Trennung beliebig super ist, ja, so natürlich kann man das auch falsch machen, in dem Sinne, dass man halt das an den falschen Stellen trennt, irgendwie in der falschen Granularität trennt.

Das ist natürlich nicht schlecht.

Und wenn man jetzt sozusagen es aber gar nicht schafft, es zu trennen und sagt, wir machen jetzt aber Microservices, um die Sachen, wo wir es halt falsch getrennt haben, nochmal zu zementieren, indem wir es auf andere Rechner packen oder 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 es halt noch viel schlimmer als vorher.

Also wenn du vorher das Problem hattest, du hast es nur 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, ja.

So ein halbes Jahr oder so.

Und dann nach einem halben Jahr fällt ja auf, so das Problem ist eigentlich noch viel schlimmer als vorher.

Und das ist halt dann, ja, da 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üssen wir mal drüber reden, wenn ich da irgendwie mehr zu weiß.

Ich glaube, da müssen wir auch eine eigene Folge zu machen zur Architektur.

Aber, oder auch Microservice versus Modulit, ja, schreiben, ne?

Auskennen.

Sag ihr uns Bescheid, hallo ich weiß ein Strategie.

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 Architecture Patterns with Python-Buch, das ich da so lese, zulese, gibt es halt.

Und ja, das fällt mir halt dazu, dann auch allen, wo man sagt, ja, super, weil das, ich kenne das, ganz viele Leute, ah, super, Microservice voll gut oder sonst wie irgendwie.

Ja, der, der, das hatte mal, glaube ich, der Autor von Closure, der Programmiersprache Rick Hickey oder Rick Hickey, ich weiß gar nicht, wie viel IP ist da nochmal, hat das gesagt.

Er meinte so, ja, es gibt immer unter Ökonomen den Witz, ja, so Ökonomen kennen irgendwie den Preis von allem, aber den Wert von nix.

Und Softentwickler kann man das halt auch anpassen und sagen, ja, Software-Entwickler, die kennen halt irgendwie die Vorteile von allem, ja, oder die Features und die, aber sie kennen halt irgendwie die Trade-offs und die Nachteile von nix.

Und das ist halt, das ist so ein bisschen, das ist halt, da ist was Wahres dran.

Und zum Beispiel, eben, das ist, da, da, wir hatten ja das letzte Mal diese Fast API-Episode oder so.

Also, das ist so, also ich weiß nicht, würde es, würde man, auch wenn ich das so, auch bei Talk-Python-Turmin 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 halt, wenn man das jetzt so macht.

Also wenn man jetzt zum Beispiel sagt, man nimmt jetzt FastAPI, nehmen wir mal einfach ein Beispiele, du nutzt halt FastAPI, SQL Model und so und alles funktioniert mehr oder weniger automagisch.

Was ist der große Nachteil an dieser Geschichte?

Okay.

Tja, da würde ich sagen, eben, da bist du schon ein typischer Software-Entwickler.

Die meisten würden sagen, ja, das hat doch keinen Nachteil, das ist ein Notfall.

Das 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, hey, wir machen das oder du stellst halt fest, irgendwie du Mist hast, du hast viele kleine Sachen, die halt serialisiert werden müssen.

Das ist halt zu langsam, das funktioniert irgendwie nicht.

Und das ging dir besser, wenn ich das jetzt irgendwie mit einem Umpai 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 einen Export der Datenbank machen und einen Import an anderer Stelle, du musst ja eine kurze Downtime-Kauf nehmen und so, alle Conversion dazwischen schalten.

Also irgendwie geht das ja schon.

Wenn deine Business-Logik da drin hängt und du hast von SQL-Model geerbt oder von Pydentic 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, nehmen wir es an, ich will gar nicht auf Fast API rumhacken oder so.

Also ich meine, dieser Ansatz ist ja durchaus verbreitet, ja, der ist ja 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 in Anführungsstrichen viel geschafft, aber du kannst es halt auch nicht mehr ändern.

Wenn du das in Django machst, hast du das gleiche Problem.

Wenn du in Django irgendwie erbst du ja von Models.

Und hast da deine Fields und so, was ist denn jetzt, wenn das aus irgendwelchen Gründen nicht mehr gut auf deine Anforderungen passt?

Jo, da musst du halt umziehen.

Ja, 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, den du damit, also 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.

Wilde Magie.

Du hast dich ganz eng an dein Framework gekoppelt.

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

Und jetzt eben sozusagen diese klassische Softwarearchitektur würde halt sagen, ja, Frameworks sind nicht deine Freunde.

Sei vorsichtig, wenn du von irgendjemandem 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 sein.

Ja, aber alles selber machen ist halt auch irgendwie ein bisschen gerade.

Nein, musst du ja nicht.

Du könntest zum Beispiel stattdessen Softwarearchitektur machen.

Ist halt nicht.

Du machst, also da könntest es halt so machen, dass zum Beispiel dein Kern, deine Applikation halt von überhaupt nichts abhängen.

Von nichts erbt 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 machst du, das ist dann eine Dependency-Injection.

Habe ich das jetzt richtig?

Ja, ja, ja, genau, genau.

Du würdest die Dependencies in umdrehen.

Du würdest halt sagen nicht, der Kern meiner Software basiert halt oder hängt halt ab von anderen Sachen, sondern du würde sagen, man dreht das halt um und sagst, 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 würde, wird das ja quasi so ein bisschen automatisiert.

Man kann das ja aber auch manuell machen.

Also manuell heißt das eigentlich, du machst es so, dass du, äh, 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, der wird zum Beispiel so eine in eine Datenbank ein Repository, ja, das muss jetzt, sag gar nicht, was das für eine Datenbank ist, sondern wird halt reingereicht, ja, dass halt bestimmte Methoden hat oder eine bestimmte Schnittstelle.

Also quasi Abstract-Base Class mit Methoden zu implementieren, die man dann verwenden muss als Insection und die man dann, wo dann klar ist, okay, das muss jetzt so und so implementiert sein, egal wie du das löstest, mir wurscht, aber Hauptsache du stellst diese Interface für mich bereit, die benutze ich dann einfach und Input, Outputs und Kodefinieren.

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, dass er schon irgendwie so richtig so fertigt wurde, ja, genau.

Kannst du mich jetzt Architekt nennen?

Ich glaube, das darf sich jeder.

Das ist gar kein Problem, was ich alles schon gesehen habe, welche Leute sich Architekt benannt.

Falls wir ist auch kein geschützter Begriff.

Ja, Informatiker glaube ich auch nicht.

Ich glaube, du darfst dich nicht Diplominformatiker nennen, aber Informatiker.

Die Titelchen.

Ja, ist auch wurscht.

Jedenfalls, wenn du halt auf diese Abstraktion 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.

Ja, ja, genau.

Der Nachteil ist halt irgendwie Django ORM und so, das ist ja schon nett.

Du sparst ja halt viel Arbeit und.

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 Cluster bauen, die musst du dann für deine Sache implementieren.

Wenn du das mit dem Django OM nutzen willst, dann musst du quasi einen Händler dafür schreiben für deine abstrakte Cluster, die dann den Django ORM benutzt, damit die Methoden, die du dir bereitstellen willst, auch dann darüber gehen.

Ja, also sagen wir mal so, du verlierst halt einen Großteil der, das sind der Gründe, warum man jetzt.

Convenience.

Der Convenience, die verlierst du tatsächlich.

Das ist halt so.

Dadurch, dass du halt Django austauschbar machst oder FastAPI austauschbar machst, ja, ich habe das, wenn man überlegt habe, zum Spaß könnte man eigentlich noch einen Flask irgendwie Entry Point davor hängen, sozusagen, wenn ich damit fertig sein sollte.

Und das wäre praktisch kein Problem, das zu machen.

Ich könnte halt Flask gegen Fast API 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 der Nachteil.

Aber ja, ich wollte es einfach mal ausprobieren, deswegen habe ich da so ein bisschen mit angefangen.

Und ja, aber man sollte sich halt, wenn man jetzt ihm diesen Weg geht und sagt, ah, ich nehme einfach ein Framework, dann ist alles schnell.

Software-Architekturen nennen und so ein bisschen hochtraben.

Ja, da muss es halt nur entsprechend verfangen.

Ja, abstrakte Interfaces bauen, damit man so ein bisschen die Dependency Insection auslagern kann und damit man reduziert die Abhängigkeiten seiner eigenen eigenen Codes von anderen Dingen und die einfach austauschen kann.

Also dieses Pattern der Dependency Insektion in diesem Fall mit diesem abstrakten Ansatz ist, glaube ich, eine richtig gute Idee, wenn man Skalierungen möchte in irgendwann.

Ja, es ist halt auch so vor- und Nachteil.

Also es hat halt den Vorteil, dass du dann eben flexible Sachen austauschen kannst und so und dann halt nicht davon abhängst.

Also wenn, wenn irgendeiner von deinen Dependency halt sich als nicht so gut erweist und du willst was anderes machen, dann kannst du das halt tun.

Auf der anderen Seite ist es halt, wenn du weißt, dass du das nie musst und dass es auch egal ist, ja, dann, also wenn du zum Beispiel eben klassische Crut-Geschichte hast, die relativ einfach ist, dann macht das keinen Sinn, da viel Architektur zu machen, weil das ist sowieso egal, ja.

Aber genau, ich mache es jetzt auch nicht, weil es nötig ist, sondern einfach nur, um zu verstehen, wie es ist.

Ich habe genug Zeit und mache da so schöne Sachen.

Ja, genau.

Genau, das ist ja.

Ich mache das ja sowieso mal

als Fahrzeug.

Ja, und deswegen.

Das ist auch irgendwo ein Selbstzweck.

Ja.

Vielleicht noch erzählen wollte, weil diesen dem, es tut mir leid, da ich immer so viel Webentwicklung mache, fehlt mir da halt dieser ganze Machine Learning-Teil so ein bisschen.

Ich bin da momentan auch nicht so richtig auf dem Laufenden.

Weil ich letztens wieder einen Podcast gehört, so, oh krass, was da alles so passiert, da wusste ich ja gar nichts von.

Also ich kann auch sein, dass ich jetzt so ein bisschen Unsinn erzähle, weil ich da nicht mehr so richtig drin stecke, aber vielleicht ist er interessant.

Also mich hat es auf jeden Fall überrascht.

Also einmal gibt es halt jetzt die Bestrebung, also du das kennst du ja wahrscheinlich auch, es gibt so große Modelle, die trainiert werden, auf irgendwie selbst-supervised trainiert werden auf quasi im Internet zum Beispiel.

Language-Modelle gibt es da diese GPT, GPT-Screen-State-Bark

und sowas.

Und die machen ja alles irgendwie so ein bisschen besser, wenn man jetzt irgendwie die verwendet, also und dann sozusagen das eigene Problem darauf feintuned irgendwie.

Und das dachte ich auch immer, das ist der Hauptvorteil, den man da hat, wenn man den Kram verwendet, aber tatsächlich können die halt noch eine ganze Menge mehr und das war mir so gar nicht so richtig klar.

Zum Beispiel bei GPT-3 ist es halt so, du kannst halt auch so Dinge machen wie Zero-Shot Learning oder Few-Shot-Learning, also gar nicht irgendwie, du feintunes es nicht mit ein paar hundert, tausend, was auch immer, Beispielen, sondern du sagst zum Beispiel GPT-3 einfach so, irgendwie, dein Job ist jetzt Übersetze von Englisch nach Deutsch.

Und du tut es das einfach so, ohne dass du ihm irgendwelche Trainingsbeispiele gezeigt hast.

Oder du sagst ihm, dein Job ist jetzt Übersetze von Englisch nach Deutsch und gibst ihm halt noch drei, vier Beispiele.

Und dann geht das auch schon ganz gut.

Und das ist halt schon krass so.

Und für viele andere Tasks geht das auch.

Deswegen glaube ich, da gibt es dann auch wieder die Frage, ist die Frage, wie man das nennt, dann Instruction-Based Learning oder Zero-Shot-Learning oder.

Die KI von Conscious so ungefähr, ja.

Ja, das weiß ich nicht, aber.

Aber es ist auf jeden Fall beeindruckend, was damit geht.

Und es gab dann halt so, tatsächlich, das wusste ich überhaupt nicht, dass es existiert gibt.

Es waren Leute, die dann meinen, naja, also es gibt inzwischen so den Job quasi mehr oder weniger von Leuten, die sich halt überlegen, wie sie Anfragen an das Modell formulieren, dass da irgendwas, was sie dann hinterher verwerten können, dabei rauskommt.

Weil man muss da auch so ein bisschen aufpassen und rumtricksen und welche Beispiele gibt man dann, um das halt noch ein bisschen zu verbessern.

Und da kann man halt, kann man halt solche großen Modelle wohl dazu bewegen, Dinge zu tun, die ganz erschauenig sind.

Genau, wie beim Copilot ist das auch so ein bisschen so.

Copilot ist auch so, ja.

Wenn du gute Beispiele gibst, also gute Methoden und so, gute Namen, gute Argumente, gute Docsprings, lernt er sehr gut draus.

Also, wenn man das in einem Projekt mal so konsistent hat, da ist es echt Gold wert.

Ja, genau.

Und ja, habe ich jetzt auch letztens gehört.

Genau, ist die Frage, wie nennt man das jetzt eigentlich?

Weil all die Sachen, wie man das früher genannt hat, das trifft es eigentlich nicht.

So Pre-Train-Modelle, das klingt irgendwie so ein bisschen, als wäre dann schon alles passiert irgendwie, aber das trifft es ja nicht, weil man muss ja jetzt mit dem Ding noch irgendwie so lange interagieren, bis man das dazu gekriegt hat, dass das macht, was man eigentlich möchte.

Also einfach nur, was waren noch die Self-Supervised, ist halt auch nicht so ganz richtig, weil es ist nicht immer Self-Supervised.

Wir müssen dazu auch noch eine Machine Learning-Folge machen, glaube ich.

Das hört sich sehr

interessant an.

Ja, aber da braucht man auch jemanden, der sich damit wirklich auskennt, nicht so der paar Professor wie ich.

Und also unklar, es gab jetzt den Vorschlag, glaube ich, von Stanford oder so, wo sie gesagt haben, lass uns die Dinger doch Foundation-Models nennen.

Weil das hätte, das macht das ein bisschen klarer, weil wir wissen auch nicht so genau, wie das jetzt, es wird es halt auch, also für Bilder gibt es das noch nicht so richtig, aber es sieht so aus, als ob das jetzt auch in die Richtung läuft, dass man das irgendwann mit Bildern und auch vielleicht mit Videos machen kann.

Und dann werden dann auch, da werden auch mal sehr, sehr interessante Sachen gehen.

Und vielleicht ist es eben auch nicht nur selbst-supervised, vielleicht kann man auch irgendwie bei ImageNet oder so hat man ja zwar rein supervised, irgendwie sozusagen.

Kann man ja auch benutzen.

Aber wir haben auf jeden Fall irgendwie so eine Klasse von Modellen, die sind sehr groß und mit denen kann man irgendwie interessante Dinge tun und es ist so ein bisschen unklar, aber das sind irgendwie die Foundation für alle möglichen anderen Dinge, die man damit macht.

Also lassen sie doch Foundation-Models sind und sozusagen da irgendwie die ganzen Themen, die halt jetzt halt ranhängen, halt irgendwie mit Abfrühstücken.

Und die Idee fand ich eigentlich gar nicht so schlecht.

Ich bin mal gespannt, ob sich das durchsetzt.

Ja, und genau.

Ja, und dann ist es halt so, dass auch der Fortschritt in dem ganzen Deep Learning-Bereich war in letzter Zeit so stark, das konsolidiert sich jetzt auch alles so ein bisschen.

Finde ich auch ziemlich cool.

Da gibt es halt irgendwie Leute, die auf GitHub irgendwie jetzt die ganzen Sachen polieren.

Also das hatte ich früher auch mal so, wenn man sich jetzt anguckt, so diese ganzen Leute, die in diesem Forschungsumfeld hält sind, wenn man sich einen Code anguckt, mh, so mh, ist halt oft theoretisch sehr avanciert und irgendwie Leute machen sich da viele Gedanken und so, sind sehr kreativ und machen irgendwie krasse Mathematik, aber irgendwie jetzt so den Code, den sie schreiben, ist manchmal schon so ein bisschen ruhig.

Also da geht auf jeden Fall noch was.

Also das ist jetzt noch nicht der letzte.

Das ist jetzt lieb ausgedrückt.

Ja, ich meine, klar, man kann ja auch nicht in allem gut sein.

Das ist halt irgendwie so, man muss sich ja auf irgendwas beschränken.

Und aber da ist auf jeden Fall noch nicht so das Ende der Fahnenstange erreicht.

Und was ich jetzt interessant fand, ist, dass es halt da Leute gibt, die aus dem Softwareentwicklungsbereich kommen, die sich das angucken und sagen, das ist ja alles, da kann man ja noch was machen und dann was machen.

Und das hat jetzt wieder Einfluss auf die Forschung.

Zum Beispiel eben aus der Kettelecke kommen da einige.

So Competitive Machine Learning oder halt auch aus der Industrie.

Also es gibt da zum Beispiel einen Ross Whiteman, der sich diese ganzen Image-Standard-Image-Modelle mal nochmal angeguckt hat und der dann im Wesentlichen herausgefunden hat, so, naja, also das, was ihr sagt, also es gibt der State of the Art sozusagen für den Score auf bestimmten Problemennetz, nehmen wir ImageNet oder so, ja.

Der wurde ja ermittelt für bestimmte Modelle vor ein paar Jahren.

So inzwischen hat es aber nicht nur Vorteile bei den, äh, Fortschritte bei den Modellen gegeben, also wie ist die Architektur der Modelle oder so, sondern auch bei den, ja, das ist aber, das spielt alles nicht so eine große Rolle, weil man kann eh nur keine kleine Bilder nehmen, weil irgendwie die Datenmengen halt sonst irgendwie schwierig für die Modelle werden.

Aber nee, wo sich was getan hat, ist zum Beispiel sowas wie, wie trainiert man die Dinger eigentlich?

Also wie sind die Hyperparameter, mit denen man, äh, die man benutzt zum Trainieren?

Wie, äh, da gibt es halt auch eine Menge.

Es klingt wirklich so, also das ist ja super interessant alles, aber ich glaube, wir sind jetzt in der Episode so oft hin und her gesprungen, dass wir da unbedingt nochmal genauer drüber reden müssen in einer eigenen Episode.

Weil das, ähm, ja, also ich finde es sehr spannend und ich glaube, das war halt komplett oft.

Ich glaube, die Leute, die vorher interessant fanden, bei CSS waren jetzt bei Machine nicht mehr dabei und andersrum waren die.

Ich bin gespannt.

Ja, wir machen auf jeden Fall noch eine Episode, du hast es versprochen.

Ihr seht, Jochen ist ja auch sehr beliebt und fand das auch super interessant.

Ich finde das super.

Vielleicht nochmal kurz zum Abschluss zu bringen.

Also es ist auf jeden Fall so, dass jetzt, dass man sagt, dass der quasi gesagt hat, also wenn man jetzt die ganzen Fortschritte, die es in anderen Bereichen gibt, jetzt nochmal mit den alten Modellen zusammennimmt, dann stimmt die Baseline nicht mehr.

Es ist halt nicht so, dass die Modelle von damals schlecht wären.

Es ist nur so, dass die Methoden, mit denen wir die trainiert haben damals, sind halt vielleicht nicht so gut gewesen.

Wenn wir die heute mit den besseren Methoden trainieren, dann, upsala, für manche Probleme sind die doch wieder State of the Art.

Also sehr, sehr coole Sachen und ja, da gibt es viel zu erzählen.

Ja.

Ja, ja.

Ja, ich glaube, dann haben wir jetzt quasi, das war das letzte Thema, glaube ich, was auf deiner Liste stand, was du noch ein paar kleine.

Ich glaube, wir haben heute genug Kuddelmuddelsalat aufgetischt.

Na gut, alles klar.

Ja, ich weiß nicht, genau, dann jetzt haben wir das Problem, ne?

Aber jetzt bist du dran, jetzt muss ich mich erstmal meinen Pick wieder nachgucken, den du mir versaut hast.

Was würdest du denn picken?

Ich muss was picken in dieser Folge schon wieder.

Ich weiß nicht, obwohl könntest

du Ja, ich pick Critical Role.

Das ist eine wunderschöne Serie, die auf Prime läuft über D<unk>D.

Falls jemand sich für D<unk>D interessiert, es gibt einen Wodcast von Messie Mercer dazu, der Critical Role heißt und der hat eine Kampagne mit seinen SpielerInnen gespielt.

Vox Machina und diese Vox Machina ist jetzt auf Prime Erschienen.

Es war eigentlich gar nicht geplant als Fernsehserie natürlich, aber irgendwie sagt es, ach, total toll, was wir hier machen.

Also das sind alles so Voice Actors und so.

Macht total Spaß, eigentlich sollte mal jemand einen Comic draus machen.

Dann hat irgendwie gesagt, ach, der hat kein Comic, ja, vielleicht doch.

Ja, da brauchen wir doch irgendwie Geld für.

Ja, dann lass doch einen Kickstarter machen, meint dann irgendwer.

Ach, Kickstarter hat irgendwer einen Kickstarter gemacht, 48 Stunden später irgendwie 11 Millionen Dollar oder so eingenommen.

Dann haben die gesagt so, hey yo, wir machen doch so eine Serie.

Und dann hat Amazon gesagt, oh, wir kaufen es.

Und hat direkt die Staffeln da veröffentlicht und die laufen jetzt tatsächlich auf Prime.

Glaube ich, die erste Staffel gerade rum.

Und das ist D<unk>D, eine Abenteurergruppe, die es live gab, quasi.

Gibt es auf YouTube, kann man die echten Abenteuer nachholen.

Also eine Folge ist, glaube ich, so dreieinhalb bis vier Stunden oder sowas.

Und die haben, glaube ich, 150 Sessions abgehalten für diese Kampagne.

Es ist also ein bisschen verkürzt dargestellt, aber ja.

Wo wir eben bei Jagshaving waren.

Was man alles verbessern optimiert kann und wie tiefer die Bald ist.

Aber egal, nur ein kleines Punkt.

Jochen, dein Pick.

Ja, ich habe jetzt versucht, den gerade zu finden.

Ich habe ihn nicht mehr gefunden.

Aber ich kann ihn beschreiben und ich reiche den Link dann in den Shownotes nach.

Es gibt Rich, also es gibt ja Typer, das macht auch schon eine Menge Command-Line-Geschichten.

Es basiert aber auch auf Klick.

Genau, Typer.

Und es gibt auch irgendwie Rich-Click oder ich weiß jetzt eben nicht, wie man es hinschreibt, aber wo man sozusagen Click und Rich irgendwie ganz nett kombiniert hat.

Und das sah sehr gut aus.

Und das war dann mein Pick.

Interessant, cool.

Ja, super, dann vielen Dank, dass ihr wieder eingeschaltet habt.

Bleibt uns gewogen.

Ich hoffe, ihr habt auf diese Episode nicht ganz so verstört wie uns.

Und beim nächsten Mal wieder ein.

Und ja, wie gesagt, schreibt uns gerne alles, was euch beschäftigt an hallo.peisenpodcast.de.

Bis zum nächsten Mal und bis dahin.

Bis klar.

Jo.

Wir bis immer.

Tschüss.

Ciao.