Hallo und herzlich willkommen bei einem Python-Podcast. Heute ist die 40. Jochen, wir haben ein Jubiläum.
Oh ja, herzlich willkommen Dominik. 40, das ist ja schon viel älter als wir sind.
Ja, fast.
Ja, zumindest teilweise.
Ja, noch.
Was wollen wir heute machen? Wir haben ja erst überlegt, ob wir irgendwas über Ensebild erzählen wollen,
aber das müssen wir wann anders, glaube ich, nachholen, weil
wir niemanden gefunden haben, der
sich mit Ansible so richtig gut auskennt, den wir ja gerne
als Gast gehabt hätten.
Wenn ihr also von Ansible Ahnung habt
und was erzählen wollt, dann sagt uns doch einfach mal Bescheid.
Das gilt auch übrigens für alles andere
Feedback, was ihr uns schicken wollt an hallo.pythonpodcast.de
Genau, wenn ihr ein Thema
habt, über das ihr gerne mal
gesprochen haben wollen würdet, dann könnt
ihr das auch gerne selber mit uns tun oder
jemanden nennen, den wir mal fragen sollen,
weil genau...
Wir haben zwar noch viele schöne Themen auf unserer Liste und so,
Aber wir lassen uns auch immer gerne bereichern mit neuen tollen Themen
Da müssen wir vielleicht nachher nochmal drüber reden, welche Themen das denn sind
damit Leute dann auch eine Chance haben, irgendwie zu sagen
ob sie jemanden kennen
Die können ja einfach ihr Thema bringen, auf das sie besonders Lust haben
Okay, dann sagen wir das jetzt zuerst, wo noch so viele Leute dazuhören, dass sie das mal machen sollen
Ja, es gibt ja so eine Burnrate
Genau, und dann am Schluss
ist ja keiner mehr übrig
Ja, aber was machen wir denn dann heute? Wir wollen eigentlich fast so ein bisschen mal wieder
kunterbunt voneinander reden
Zeugs besprechen
Eben so Metageschichten vielleicht tatsächlich mal wieder
Das haben wir jetzt auch schon länger nicht mehr gemacht
so eben, über was man mal reden könnte
oder ja, was wir so tun.
Ja, so richtig Meta,
ja, Meta bei was, ja.
Bei Podcast ist es nicht Meta, bei Python ist es
eigentlich so WebDev-Meta, oder?
Also was man so alles benutzen kann, an Tools
oder so. Ja, ich meine, wir machen ja
relativ viel Webentwicklung, oder ich
mache gerade relativ viel Webentwicklung
seit einer ganzen Zeit.
Ich weiß auch nicht, warum das so ist, weil ich
mache ja eigentlich auch viel Maschinenleutent-Kram und so,
oder habe auch mal viel gemacht, aber in letzter Zeit
und das ist irgendwie mehr Webentwicklung, obwohl das andere Ding ja auch gerade so halbt.
Ich weiß nicht, woran das liegt. Ich muss da vielleicht einfach mehr Machine Learning wieder machen.
Ich wollte gerade sagen, ich will erst mal den Job wechseln, Jochen.
Ja, das kann natürlich auch sein.
Ja, gut.
Vielleicht Webentwicklung ist eigentlich so ein bisschen Convenience-Software-Entwicklung.
Das kann man mal so ein bisschen dazwischen schieben.
Vielleicht musst du was Lippes machen.
Das ist nicht so schlimm.
Also Machine Learning auf Blockchain oder so.
Oh mein Gott.
Ja, das ist jetzt so, das weiß ich nicht.
Duo in Finale.
Ich weiß nicht, ob ich das machen möchte. Nee, eher nicht. Aber genau, vielleicht fangen wir einfach mit News an.
Ja, mit News.
Okay, warte mal, die Kapitelmarke News.
Dafür musst du dich jetzt aber ziemlich stricken. Das müssen wir noch optimieren.
Das muss ich. Der Raum ist noch nicht ganz optimal, das stimmt.
Okay. Also wir haben gerade ein Kapitelmarke.
Ich sehe schon, dass die Kapitelmarke irgendwie am Anfang jetzt sitzt und nicht da, wo ich sie eigentlich haben wollte. Irgendwie funktioniert das alles noch nicht so richtig.
Ja, in Melkrotte wird eher eine Laberfolge.
Ah, was ist denn da schon wieder kaputt?
Okay, ich stelle jetzt hier mal das Ding in Ultraschall auf.
Wir benutzen übrigens Ultraschall zum Aufnehmen.
Ja, Ultraschall 5, sehr gut.
Ein Plugin auf Reaper.
Ja, genau.
Wie produziert man Podcasts?
Das haben wir noch gar nicht.
Haben wir das schon mal gesagt, wie man einen Podcast produziert?
Oder wie wir unseren produzieren vielleicht?
Also Kurzversion ist tatsächlich,
wir nehmen das auf mit diesem Plugin für Reaper.
Reaper ist eine Software, die ist eigentlich kostenlos, aber...
Nein, nein, nein.
Ja, also in der Testversion, in der Evaluation-Version gibt es, also erstmal zum Ausprobieren kostenlos, ich wollte jetzt sagen.
Ja, okay.
Und dann gibt es halt dann dieses Plugin Ultraschall für Podcasts, was echt cool ist.
Und danach machen wir noch so Post-Production mit Auphonic.
Ja, und Shownotes schreiben und so, das machen wir auch so, leider nicht automatisch, sondern auf Auphonic.
Ja, aber das kann man ja
einigermaßen gebrauchen, dann kann man doch mal nachschauen,
was wir für einen Quatsch irgendwann mal erzählt haben.
Vielleicht ist da ein Schumanns drin, wenn das denn jemand
aufgeschrieben hat.
Genau. So, jetzt kann ich auch die
News-Kapitelmarke nochmal verschieben.
Ich kann ein schlechtes Gewissen haben.
Jetzt haben wir aber auch wirklich ein bisschen Meta über Podcasts.
Das ist doch schon mal etwas. Du wolltest bestimmt auch mal über andere Podcasts
gleich erzählen.
Ja, aber das war auch Meta.
Das war News.
Das ist ein bisschen Neues.
Also ganz schick.
Task Groups
gibt es jetzt, ist gerade gemerged
worden für Python 3.11.
Okay, was ist Task Groups? Fangen wir vielleicht erstmal
damit an. Naja, also
sagen wir so, es gibt ja irgendwie bei,
also es gibt eine Schwachstelle bei
Python Async
Geschichten, die halt da schon
oft irgendwie
ja,
Leute ein bisschen
depressiv gemacht hat, oder keine Ahnung, oder
geagert hat, ich glaube,
das ist am besten
Also zum Beispiel
Trio ist eine Bibliothek, die sich halt mit diesen ganzen Problemen
beschäftigt. Es ist halt auch schwierig.
Ja, Trio.
Nathaniel Smith hat die geschrieben.
Es gibt ja diverse Implementationen
in diesem Async. Ich habe jetzt ganz viel gehört, aber ich habe
immer noch nicht genau verstanden, was denn das Problem dabei ist.
Also das Problem ist halt,
also sagen wir mal so,
wir befinden
uns, was diese Async-Geschichten angeht, ja so ein bisschen
in einem ähnlichen
Stadium wie, als man
irgendwann mal angeführt hat, strukturierte Programmierung
zu verwenden, anstelle von
Gotoh oder so.
Das ist jetzt ein bisschen abstrakt.
Es ist jetzt so, als wäre es nebenläufig
ein zweiter Gedanke losgelaufen, der aber nicht mit dem anderen
wieder zusammengekommen ist, weil ich den nicht einsammeln konnte.
Ja, aber genau.
Also nachdem man strukturierte Programmierung, also mit Funktionen
und so oder Prozeduren irgendwie eingeführt
hatte, da musste man auch erstmal sich umgewöhnen oder so, weil man
das bisher immer anders gemacht hat. Also man strukturierte Programmierung
bedeutet, man schreibt nicht von oben nach unten irgendwas durch
und sagt dann, okay, geh wieder zu dieser Zeile und
macht da irgendwie weiter, sondern man
kennt das in logische Blöcke,
die man aufrufen kann.
Wo man am Anfang weiß,
was da reinkommt und am Schluss weiß, was da wieder
zurückgeht und sozusagen
damit man das halt nur noch...
Nennt man das eine Closure?
Nö.
Closure ist eine
innere Funktion,
die halt Zugriff
auf etwas hat, was
ja,
also du kannst zum Beispiel, wenn du eine Funktion
in der Funktion hast und du gibst jetzt sozusagen
die innere Funktion zurück,
dann hat die ja noch Zugriff auf den Scope der Funktion,
aus der sie rauskommt. Und da kannst du
jetzt Sachen drin definieren.
Also zum Beispiel Closures ist halt das allgemeine Prinzip
hinter, wie man Dekoratoren in Python
dann implementiert. Also Dekoratoren
machen das. Die rappen
sozusagen die Funktion, die man dekoriert,
in eine innere Funktion rein.
Bin ich mir gerade nicht ganz sicher, ob wir die Menschen, die uns zuhören,
jetzt nochmal abhören dabei, was weiß ein Dekorator sind?
Oder ob die das alles schon wissen?
Da können wir mal eine Episode dazu machen, die Quadrant, super Sache.
Eigentlich schon, ne? Ja, okay, dann machen wir eine eigene Episode dazu.
Also, man
man webbt dann quasi
die Funktion und dann, da die aufgerufen wird
und das Funktionsobjekt dadurch die Gegend gereicht
wird, muss man halt Objekte oder Dinge
reingeben können, rausgeben können und kann halt vorher
und nachher was machen.
Oder da irgendwelchen Kontext setzen, genau.
Und, ja,
also,
das ist nochmal was komplizierteres, aber
also Funktionen sind eigentlich relativ einfach, aber
trotzdem, wenn man das halt nicht gewohnt ist, dann muss man das umstellen
und es ist die Frage, wie arbeitet man damit, was macht man
jetzt eigentlich in einem Fehlerfall und so und all diese
Probleme haben wir jetzt nochmal so ein bisschen, weil
wir jetzt uns irgendwie überlegen müssen, okay
wenn wir jetzt async Sachen machen,
wie machen wir das denn richtig und
zum Beispiel ein Problem, was jetzt
halt den Leuten öfter mal auf den Fuß gefallen ist,
vor allen Dingen die Bibliotheken entwickeln,
als Endanwender oder
Endproduzer von diesen Geschichten
hat man das eigentlich gar nicht so oft,
aber kann sich ungefähr verdeutlichen,
also wenn man jetzt zum Beispiel, man hat halt so
also was man mit AsyncIO oft macht, ist sowas wie
zum Beispiel, also im einfachsten Fall
man hat eine Liste von URLs, die man abfragen möchte
und dann sagt man halt irgendwie
AsyncIO, oder man sagt halt
Gather den ganzen Kram
und kriegt dann halt das alles zurück.
Was passiert denn?
Was macht denn das Gather jetzt genau?
Das wartet, bis sie alle einmal
durch sind, alle Awaiten. Gather macht
Await eins nach dem anderen und zwar in der Reihenfolge, wie die Liste
drinsteht, oder das letzte.
Die Reihenfolge gibt es so ja nicht mehr.
Naja, aber
und die laufen ja nebenläufig und eins ist ja zuerst fertig.
Ja.
Und eins zuletzt fertig.
Und Geza wartet, bis alle fertig sind.
Genau.
Das
sozusagen, also man muss es halt noch erwarten,
aber das wartet, bis halt alle fertig sind.
Und die Ergebnisse sammelt das auch?
Oder gibt es da Ergebnisse?
Ja, also man kann da
durchaus auch, wenn da halt Ergebnisse
zurückkommen, jetzt weiß ich jetzt nicht genau was mit all den Dingern,
wenn da jetzt unterschiedlich, also normalerweise hast du eine Liste von Sachen,
wo das ist das gleiche, wo Liste von Responses
oder so zurückkommt. Dann kriegst du halt die Liste von
Responses dann halt
zurück, denke ich.
Wenn das jetzt unterschiedliche Sachen sein sollten,
weiß ich gar nicht so genau.
Ich bin gar nicht so sicher,
was dann passiert.
Wahrscheinlich kriegst du halt eine
Liste, der
wie auch immer die Liste aussieht.
Keine Ahnung. Aber das
Problem ist halt eben, und das was halt nicht so gut
geht, wenn du jetzt sagst
async-io-gether und jetzt passieren
aber mehrere Dinge. Jetzt hast du
zum Beispiel einmal einen Connection-Error irgendwie
bei nur einem URL,
sondern bei einem anderen Ding hast du aber
irgendwie einen, weiß ich nicht,
not authorized und bei einem anderen hast du
irgendwie
Authentication-Error oder was auch immer.
Du hast halt so unterschiedliche Fehlertypen.
Du kannst
jetzt aber im Interpreter, der kann
immer nur eine Exception weiterreichen.
Was passiert denn jetzt? Du kriegst die aber zu unterschiedlichen Zeitpunkten.
Wenn du jetzt hast
try irgendwas, gather,
was passiert denn jetzt, wenn du accept sagst?
Ja, dann sollte die accept, die zuerst
rausfliegt, sollte rausfliegen. Aber eigentlich sollte man die ja vorher
catchen, oder? Also innerhalb des
Dekor-Routines und nicht...
Ja, willst du ja aber auch nicht. Also du willst ja die exception
an der Stelle fangen, wo du irgendwas mit der machen kannst.
Also es hängt halt davon ab natürlich,
aber es ist halt so die Frage, wenn du die Frage
gefangen hast, okay gut, dann kriegst du sie ja auch nicht mehr.
Aber wenn du jetzt mehrere
Exceptions hast, die halt da
auftreten, was passiert denn dann? Und ja,
die Antwort momentan ist halt irgendwie,
ja, ist doof, weil
du kannst, es gibt
sowas wie Chained Exceptions, das sieht man manchmal
auch gerade bei so Webframeworks häufiger,
irgendwie, dass halt irgendwas eine Exception wirft
und dann dir sagt, ah, also
das ist passiert, also oder ein Test
passiert auch häufig,
während ich versucht habe, diese Exception zu werfen,
ist halt das passiert oder keine Ahnung,
oder sowas geht auch,
aber das bildet
das halt auch nicht ab, was du dann eigentlich können
müsstest, wenn jetzt irgendwie mehrere
unterschiedliche Exceptions halt aufgetreten
sind oder ein ganzer Baum, also im allgemeinen Fall
ein ganzer Grafbaum von
Exceptions, die halt irgendwie, so
das geht irgendwie nicht. Das kann auch tatsächlich der Interpreter
nicht. Und
ja, das ist halt ein Problem. Und dafür gab es
ein PEP
654, Exception Groups
and Except.
und der Code dafür ist jetzt
irgendwie
vor Woche oder so,
ein paar Tagen, gemerged worden
und alle so, huu, und das kommt in 3.11
und das bedeutet halt, dass man
jetzt quasi damit sauber umgehen kann. Also Trio
habe ich deswegen angesprochen, weil das war
halt so ein Ding, damit umzugehen.
Also der nannte seinen Ansatz
da auch irgendwie
Structured Concurrency und
der hatte dieses Konzept von Nurseries,
die man da benutzen kann, um halt damit dann sauber
umzugehen. Das hat eine Asynchroge, glaube ich, schon mal erwähnt.
Das hat eine Asynchroge und ich weiß nicht,
ob wir das wirklich, also ich glaube, das hat
damals schon niemanden so wirklich
gesagt.
Wahrscheinlich ist das jetzt auch nicht anders. Aber ich finde es
interessant und
es ist aber auch ein kompliziertes
Thema und
sagen wir so, die
Kurzfassung ist, es geht jetzt alles, also ab 3.11.
wird es deutlich besser. Es gibt da diverse Leute, zum Beispiel auch
der Juri
Selim Zvanov,
der mit
mit HQL und HDB.
Der hat auf Twitter relativ enthusiastisch
gesagt, so 3.11, das ist voll gut,
dass das jetzt drin ist. Wir haben schon seit Jahren Probleme
damit und jetzt ist es endlich
sauber gelöst und damit ist quasi
Python hat jetzt irgendwie
sehr gute Unterstützung im Vergleich zu allen
anderen Sprachen eigentlich.
Spielt da jetzt ganz vorne mit.
Und juhu!
Also das kann man
auf jeden Fall schon mal erwähnen, dass das irgendwie ziemlich cool werden
wird.
Jetzt muss ich nur noch verstehen, wie man halt so eine
Exception Group.
Ja, da musst du dir den
Pep angucken, da steht da schon, wie man
damit umgeht.
Ich glaube, man kann das ganz normal
in die Exception so auseinanderschreiben.
Wir haben jetzt relativ viel.
Also ich habe zwei verschiedene Exceptions.
Wir fangen mit zwei an, die gleichzeitig auftreten.
Also einmal, keine Ahnung, Autopsy-Grundverweigerung,
einmal Connection abgebrochen.
In zwei verschiedenen Threads.
Was machen die?
Du musst ja nicht Threads sein.
Aber ist auch egal.
Die haben auch dieselbe API oder auf eine andere API zugegriffen, ist auch egal.
Also Hauptsache, die schmeißen beide irgendwie Exceptions.
Aber der Zeitpunkt
ist egal oder nicht egal,
wenn das aufgetreten ist.
Naja, du kannst jetzt nach dem
Zeitpunkt ordnen, du kannst aber auch irgendwie anders ordnen,
je nachdem, wie du willst. Also du hast halt eine Exception-Group
und darunter hast du jetzt dann halt unterschiedliche
Exceptions.
Und dann hast du halt quasi einen Baum.
Eine Exception-Group kann halt wieder
unterschiedliche Exception-Groups drunter haben,
die dann wieder Exceptions drunter haben.
Das ist halt ein Baum von...
und wofür brauche ich das?
Naja, also wie gesagt, als Endanwender hat man
da den Fall, dass man das wirklich braucht, gar nicht so häufig,
aber wenn du jetzt halt irgendwie so eine High-Performance-Datenbank
Library
Geschichte baust, sowas wie
zum Beispiel
AsyncPG oder so, dann
kann das durchaus passieren,
dass dann halt
in solche Sachen reinläufst,
wo du dann gerne irgendwie was
gut, wo du zum Beispiel einfach noch
einen ordentlichen Traceback werfen wollen
würdest, wo man sehen kann,
was passiert ist.
Weil wenn du das auf 1 runter dampfen musst
und dann rausschmeißen und sagst Datenbankerror,
sagen wir mal so, gibt es eine Zahl zurück,
Datenbankfehler,
dann ist das nicht sehr hilfreich.
Du musst halt, aber alle Sachen
kannst du nicht angeben, weil du hast
nur eine Exception. Also weil die erste, die
quasi dann geracet wird, dann die die rausfliegt
und die anderen gehen dann unter, das wäre das Problem
sonst. Genau, ja. Ja, okay, und ich will halt
quasi, dass die durchgereicht werden. Du willst die
irgendwie behandeln können, ob du sie jetzt
rausprintest oder irgendwie darauf reagierst
oder so, ist ja nochmal eine andere Sache, aber du kannst
sie jetzt handeln. Also das wäre
quasi so, als müsste ich so eine Art
Exception Cache bauen und
dann irgendwann alle Exceptions in
diesem Exception Cache zurückgeben, anstatt die zu raisen,
die quasi in diesen Exception Cache reinspeichern
und ganz am Ende alle
Exceptions da drin sind in eine Custom
Exception zusammenfassen und raisen.
Keine Ahnung, wie das jetzt
dann Leute gerade machen.
Da gibt es unterschiedliche Ansätze wahrscheinlich,
aber jetzt geht es halt so, dass es
cool ist und sauber.
Ansonsten hatten wir noch
iPython,
erste Major Release seit drei Jahren
oder so.
iPython 8.
Ja, okay.
Ehrlich gesagt, so wahnsinnig viel Neues ist da gar nicht unbedingt.
Also außer Black ist irgendwie neu.
Da mussten sie auch ein bisschen zurückrudern.
Das hat Leute irgendwie auch böse überrascht.
Das haben wir doch letztes Mal noch gelobt.
Aber im Prinzip ist es eigentlich
schon richtig.
und
ja, ist es viel
deprecated worden von Dingen, die man
nicht mehr braucht und so. Und ich glaube, ich habe es auch schon,
ist es nur Beta, ist es noch nicht
stable, aber
ich habe es auch schon, also wenn man es einfach so
installiert, man pinnt es nicht runter oder so,
sondern man sagt einfach nur piv install
ipython und dann kriegt man das halt.
Und funktioniert bei mir auch schon super.
Ich verwende es schon
die paar Tage, die es veröffentlicht ist
auf jeden Fall und da hat es bisher immer getan.
Ja.
Genau, ja, ansonsten
so war es, ich glaube, wir haben jetzt irgendwie
super viele
Episoden in letzter Zeit aufgenommen,
weil gar nicht so viel passiert ist,
weil gar nicht so viel Zeit vergangen ist.
Ja, okay.
Ich weiß nicht, hast du noch irgendwas?
Wir machen nochmal Werbung
dieser Episode.
Oh ja, genau, das müssen wir dann jetzt auch machen.
Also, diese Episode kommt wieder mit der
freundlichen Unterstützung von NordVPN.
Ja, und
schnappt ihr den Exklusiv-Deal und ein Geschenk
obendrauf zum NordVPN-Geburtstag.
Gehe auf
https
nordvpn.com slash pythonpodcast
und sichere dir den
Wahnsinnsteal jetzt auch komplett risikofrei
mit 30 Tage Geld-Zurück-Garantie.
Also das ist
eine Geschichte, die man durchaus mal machen kann.
Also, ja,
NordVPN, VPN-Anbieter,
da
kann man sich zum Beispiel irgendwie im Urlaub
auch darauf verlassen, dass man dann weiter Netflix
gucken kann, was man ja sonst
manchmal hat man da so Probleme zu Video-Blocking und so
und damit kann man das irgendwie relativ
einfach umgehen oder halt auch wenn man
irgendwie sonst Konnektivitätsprobleme
hat, dann kann man aber auch irgendwie da
was gegen tun mit und
ja, hat viele
Server in allen möglichen Ländern
und so, also ist auf jeden Fall irgendwie
einer der größten Anbieter da in dem Bereich
und ja, kann man
ja einfach mal ausprobieren und auf
HTTPS,
www.notrpn.com
und die den Wandelstil sichern, der jetzt auch komplett
risikofrei mit der 30-Tage-Geld-Zurück-Garantie
ist.
Wunderbar.
Worüber reden wir denn heute?
Die ganzen Tipps,
Tools im Web und
CSS-Frameworks und
vielleicht fangen wir damit an.
Was für ein CSS-Framework benutzt denn du,
Jochen?
Ja, irgendwie gar nicht.
Ich habe vielleicht gesehen,
Podcasts zu unserer Schande in
Bootstrap, weil das Einzige, was wir gemacht haben
für Styling ist Import CDN
vom, also Bootstrap vom CDN.
Ja, das weiß ich gar nicht mal. Ich glaube, das mache ich tatsächlich nicht.
Aber das mache ich.
Oh Gott, das ist ja nicht schlecht.
Tja, wir müssen das
irgendwann mal anfassen. Weil ich würde sagen, das sollte man
natürlich eigentlich auf keinen Fall machen, sowas.
Aber weil
ja, das ist natürlich extrem unsicher. Das erinnert
mich an was?
Weiß das wirklich? Ja, ist das nicht so?
Ich meine nicht,
und
CodejQuery.com
Oh mein Gott.
Bootstrap CDN.
Oh nein.
Das war mir gar nicht so klar.
Kontrolle ist besser als...
Ja, ja, dankeschön.
Dann ist mir das jetzt auch bewusst.
Ich dachte, ach, sowas mache ich aber nicht.
Aber doch, mache ich schon. Kacke.
Ja, also Bootstrap ist raus.
Also sagen wir so, das benutzt man
halt natürlich dann, wenn man keine Zeit für irgendwas anderes hat.
Dann macht man einfach Import Bootstrap
vom CDN und dann sieht alles irgendwie ein bisschen
besser aus. Das hätte man gar nicht gestylt.
Aber auch nicht viel besser, ehrlich gesagt.
Ja, vor allen Dingen ist es halt das, was
in dem Django-Cookie-Cutter-Template
mit dabei war. Deswegen habe ich das vorhin gesagt.
Du benutzt ja kein Cookie-Cutter
von...
Eigentlich seit einiger Zeit nicht mehr, aber ich
habe es lange verwendet, ja.
Ich habe es auch ein bisschen mal ausprobiert. Das war nicht so ganz
mein Ding.
Also ich
benutze inzwischen gerne
irgendwie tatsächlich Startproject oder halt auch das,
das habe ich jetzt letztens wieder verwendet,
das Project Template,
weil man kann ja dem Startproject auch
Project Templates mitgeben von Johannes.
Das gefällt mir eigentlich tatsächlich auch ganz gut.
Und Cookiecutter ist einfach
es mir zu viel
Zeug, das ich irgendwie nicht brauche.
Also ich habe eigentlich meine eigenen Skeletons einfach
geschrieben, also so zwei, drei Templates für
Sachen, die ich manchmal brauche. Django mit Postgres, Django
Minimal, Farbpapier
und dann klone ich die einfach.
Ja, kannst du halt
auch machen, aber dann bleiben halt manchmal
so Reste übrig. Ja, aber das ist nicht viel.
Also ich weiß ja dann wo und ich habe mir das da so ein bisschen
weggescriptet, dann kann ich einfach
zwei Skripte ausführen und dann habe ich es einmal replaced
und dann schmeiße ich drei Dateien weg, die ich nicht brauche
und dann ist es gut. Also es ist halt mein
Zeug, ich kenne mich da ja auch aus und das geht aber dann wirklich schnell.
Und da ist halt aber auch dann das bei, was ich will.
Ja, also
es ist halt
irgendwie, also ich bin da noch nicht bei null.
Ja, andersrum ist es, du fängst halt bei null an und dann musst du aus allen alten
Projekten, wo du das benutzt hast, das jetzt mal reinkopieren.
Das geht auch nicht schneller.
Ja, aber
für sowas hast du ja normalerweise
ein Template, damit du das nicht
aber es ist wirklich, also ich habe auch
ich würde jetzt nicht sagen, dass es
da irgendwie eine Lösung für das Problem gibt, weil
es ist irgendwie, ich
habe inzwischen auch, also
am Anfang fand ich das
tatsächlich hilfreich, weil
es gibt ja so viele Settings in Django
auch, das ist halt echt eine Menge Zeug
dass man gar nicht weiß, wie man das alles
setzen soll und wenn man vor dieser Aufgabe
steht, ohne jetzt wirklich damit
mit schon langer Erfahrung zu haben.
Dann ist man so ein bisschen, also jedenfalls hatte ich das am Anfang
das Problem, du stehst halt wieder
wie so ein Ox von Berg Ja gut aber wenn du das jetzt von PyDanny nimmst also tats das Komplett mit Cookie Cutter das ist ja derselbe Typ der auch Two Scoops of Django Ja das Buch geschrieben hat oder die diversen
Bücher, die es jetzt in dem Thema gibt.
Aber
da ist so viel Zeugs drin.
Da ist so viel Zeugs drin.
Ja, die Hälfte brauchst du nicht.
Ja, aber das ist halt die Frage. Am Anfang
weißt du halt nicht, was du brauchst und was du nicht brauchst.
Ja, aber
für Anfänger würde ich auf gar keinen Fall
Klar, weißt du noch nicht, was du nicht brauchst, aber das würde ich
auf gar keinen Fall machen, weil ich würde blank Django nehmen
als Anfänger. Ja gut, also
für mich war das gar nicht so ein schlechter Weg,
aber inzwischen mache ich das halt auch nicht mehr,
weil ich jetzt sagen würde, okay, ich weiß jetzt, was ich
alles nicht brauche und ich brauche den meisten Kram.
Vor allen Dingen ein Ding, das mich
von dem Django-Kurkikata
komplett weggebracht hat, ist halt, dass die
halt irgendwann, das war auch nicht so,
das war am Anfang ja nicht so,
am Anfang war das komplett ohne Docker und
dann haben sie irgendwann gesagt, okay,
das jetzt für unterschiedliche Plattformen, das wird halt
und Jochen unterhalten sich über die Programmiersprache Python
mit drin ist, während der aktuellen
Geschichten, aber ja, also
genau, eigentlich ist das natürlich nicht so
schön. Ich habe jetzt auch letztens gesehen, wie groß
Bootstrap eigentlich ist, das war mir auch nie so klar, das ist ja
irgendwie alles ziemlich riesig.
Und dann eben hat das noch so
Dependencies of jQuery und so, das sind ja alles Zeugs,
das man heutzutage im Grunde nicht mehr wirklich haben will,
braucht und so, aber es ist halt
irgendwie dann alles immer noch mit dabei.
Ja, also Foundation gibt's noch,
das habe ich von Johannes mal...
Ja, Foundation ist so quasi
so ähnlich wie... Ja, auch so, du musst halt
eigentlich. Du schreibst halt nichts, importierst halt
einfach irgendwas vom CDN oder kannst es natürlich
auch vom Lokal. Und es sieht halt ein bisschen hübscher
aus. Man kann natürlich immer nasteilen, wenn man will.
Dann gibt es noch
Materialize und
UIKit.
Und das sind alles immer so große klassenbasierte
CSS-Sachen oder Post-SS oder so,
wo man halt dann seine Klassen,
vordefinierte Klassen hat, die dann irgendwelche tolle Magie
machen. Ja, oder Semantic
UI habe ich jetzt auch gesehen, dass das viele Leute
verwenden. AntDesign.
Das kenne ich nicht. Das ist
und das ist auch total schräg.
End.design.
Das ist so
was Chinesisches.
Das hat mehr
Stars aufgetappt als Django.
Und
ist irgendwie
in China verwendet. Das sind Millionen Leute.
Aber hier kennt man das Ding gar nicht so sehr.
Ja, ist auch eigentlich...
Wahrscheinlich verwendet es deswegen Leute,
weil es gute Dokumentation auf Chinesisch hat.
Man weiß es nicht.
Ja, mag sein.
Dann gibt es noch Bulma. Das benutzen zum Beispiel
viel von den VJS-Leuten, also wenn man
irgendwie jetzt auch V-Mastery oder so Kurse macht.
Da gibt es so ein paar Leute, die Bulma machen,
fand ich, das hat mich nicht so ehrlich
begeistert. Ist vielleicht eher so für...
Ja, aber das ist glaube ich in der gleichen Kategorie
wie eben, also das habe ich ja auch unter
Utility First,
CSS-Frameworks, genauso wie Tailwind.
Das ist ja auch... Ja, genau, aber
Tailwind würde ich sagen,
so mache ich das. Okay.
Ja, also ich finde es sehr, sehr toll.
Ja, ich habe auch viel Gutes gehört und habe aber auch Leute schon stöhnen gehört, also ich weiß es nicht.
Ja, also wir haben im Vorfeld jetzt kurz drüber gesprochen, du hast es mir so oben, Moment, also ich habe es schon nicht benutzt, aber ich habe ja gehört A und B und C und die haben gesagt, das ist doof und...
Ja, genau, aber das Problem ist halt immer so, bei diesen Entscheidungen,
ich meine, wahrscheinlich ist das einfach alles Unsinn, muss man irgendwas anfangen,
aber ich habe ja keine Ahnung davon.
Ich habe aber jetzt, reden wir da schon fünf Minuten drüber,
und ich habe ja auch eine Liste mir dann gemacht, weil ich dachte,
vielleicht muss ich da mal von 20 Dingern, die es hier irgendwie gibt,
die ich mir alle mal angucken muss.
Ich denke jetzt so, ich habe noch überhaupt nicht angefangen,
jetzt muss ich schon zwischen so vielen unterschiedlichen Sachen aushalten,
ich habe absolut keine Ahnung, was ich da machen soll.
Oh mein Gott.
Und dann eben, genau, soll man jetzt das selber machen?
soll man BAM machen, soll man irgendwie
Utility-First machen, soll man
ein Framework nehmen, soll man SAS nehmen, LESS nehmen,
Post-CSS, irgendwie
was auch immer. Ich weiß es doch
alles nicht und ich
habe keine Ahnung. Ja, ich würde tatsächlich
Table nehmen. Ja, gut, dann fange ich mal mit. Aber du hast ja gesagt,
das ist ja alles nur für Low-Budget.
Und ich bin ja eher
so, ich persönlich bin ja eher so
der High-Budget-Typ.
High-Buller, ja.
Finde ich, ich muss mich da schon
irgendwie so ein bisschen positionieren, ansonsten
nicht, dass man da irgendwie
mit dem falschen Ende rauskommt.
Das wäre nicht gut.
Ja, aber
ich weiß es halt nicht.
Es gibt noch andere Sachen. Es gibt noch die ganzen Mini-Dinger.
Habe ich jetzt gesehen bei
wie heißt der noch?
Andrew Johnson
hat das verwendet. MVP
CSS.
Ja, das kenne ich auch nicht.
Super Minimal und davon gibt es dann halt auch wieder ein paar.
Es gibt Mini-CSS.
Ja, da muss man immer CSS sein.
Also ich muss jetzt nochmal Talvand
nochmal loben, weil
es sieht hässlich aus auf den ersten Blick,
weil das das HTML so ein bisschen
bloatet. Du hast halt in deinem
HTML ganz viel mehr Klassen drin, die halt direkt
das Styling machen, aber dafür hast du halt eben
keine extra CSS-File mehr, musst nicht hin und her
switchen und eigentlich steht es meiner Meinung nach
genau da halt die Definition des
Styles drin, wo es halt hingehört und zwar genau
an dem HTML-Element.
Und das finde ich
super angenehm und da man eh
meiner Meinung nach ja immer so wieder
benutzbare Komponenten aktuell so hat.
Ist das mit der Redundanz hier auch
nicht so schlimm und
ja, wenn du dann halt so ein Hot Reloading
weit noch nebenbei anhast, dann
siehst du halt jede Änderung der
Farbe, schreibst halt Red
als Klasse hin und dann
ist es Rot und dann schreibst du
Red wächst mal Blau und dann ist es direkt Blau
und das ist einfach, das ist so ein bisschen
wie den 90ern HTML-Coden.
Da muss man das ja auch alles noch
direkt hineinschreiben.
und ich mochte das.
Okay, ich habe das weder in den 90ern gemacht, noch jetzt
oder dazwischen irgendwann, aber gut.
Na ja, jetzt
muss ich wohl doch irgendwie mal.
Ja, das musst du auf jeden Fall mal angucken.
Wir haben ja auch eben noch über Winly kurz gesprochen,
das hast du ja auch noch gehabt. Da gab es ja eine lustige...
Also über Tailwind,
da gab es einen neuen Releaser, das hätten wir in die News packen können.
Ja.
Es gab eine
Working Draft Episode letzte Woche oder so was
über Tailwind
CSS3
wo auch irgendwie der
Tenor war, so eigentlich ist ganz gut und
die Vorteile sind halt irgendwie, dass man jetzt nicht mehr
also früher war es so ein Default-Fall, hat das halt irgendwie
immer
die gleiche Größe an CSS ausgelegt.
Ja, man musste halt manuell purgen die
CSS-Dinge, die man nicht haben wollte.
Die musste man dann weg purgen, dass der
die Falle nicht so groß wurde, ja.
Genau, und das passiert jetzt irgendwie alles automatisch
und man
muss auch nicht mehr Node.js verwenden, sondern
es hat irgendwie Standalone
Command-Line-Utilities
irgendwie für all die Sachen.
Und das ist ja schon sehr nett.
Da dachte ich auch so, oh, das klingt aber gut.
Und dann eben hieß es da auch, ja, das kommt
aber von den Leuten von Winnie oder so.
Ja, also Winnie hat ja Tailwind geklaut und dann
Sachen so ein bisschen halt faster gemacht
vielleicht oder so, so ein bisschen mehr Opinion reingebracht.
Dann haben sie das halt wieder zurückgeklaut.
Und dann haben sich die Winnie-Leute
beschert, dass sie nicht gecredited
werden für diese Geschichten.
Und dann hat irgendjemand anders gemeint, so, ah,
ihr habt das auch nur von mir wieder geklaut.
und so. Keine Ahnung.
Das verflüstert sich auf einmal so, als wären das jetzt irgendwelche Geheiminformationen.
Nö, das ist es nicht. Aber ich,
keine Ahnung.
Also ich mag tatsächlich auch die Bezahlsachen von
Table & Consent kennen. Es gibt ja so vorgefertigte
UI-Komponenten, die man sich kaufen konnte.
Und das Projekt zu unterstützen ist von denselben Leuten, die
das Projekt geschrieben haben.
Ja, es gibt ja auch
so ein tolles Buch, irgendwie Refactoring UI
oder so. Ja. Habe ich mir
auch irgendwann mal gekauft, aber habe ich dann nicht gelesen.
Vielleicht sollte ich das auch mal machen.
Vielleicht sollte ich damit immer starten.
irgendwie mal ein Buch lesen oder so. Das könnte vielleicht
hilfreich sein.
Eine Geschichte, die tatsächlich interessanter
aussieht als diese Myriade an
unterschiedlichen CSS-Arten,
Frameworks, Minimal-Dinger, die man
so benutzen kann, die ich
letztens gesehen habe, ist
Missing.style.
Und zwar, weil das halt
aus dem HTMX-Umfeld kommt.
Und da Leute
sich überlegt haben, okay,
das fehlt halt noch. Also wenn man
HTMX macht, das mache ich jetzt auch relativ viel,
und damit bin ich eigentlich super
zufrieden mit und ja, aber wie macht man das
denn jetzt, weil da ist ja auch viel
Animationsgeschichten oder so drin,
die das dann Sachen verschwinden, wenn man irgendwo drauf
klickt oder auftauchen und so
Transition-Effekte und so und
ja, da haben sie überlegt, okay, dann brauchen wir eigentlich
genau dafür eins, aber wir wollen vielleicht nicht
so ein super
all-in-one
Riesending haben, sondern nur für die Sachen,
die wir da benutzen, irgendwie so ein
CSS-Geschichten mitrahmen und
sozusagen der Missing-Link
irgendwie.
Soll das irgendwie so sein? Das kann man sich auch mal
angucken. Also da werde ich auf jeden Fall auch mal drauf gucken,
was die da machen. Und das
klang auf jeden Fall interessant, weil das fehlt halt tatsächlich.
Also bisher muss man dann halt diese ganzen
Transition-Geschichten
halt irgendwie in sein CSS mit reinfrickeln
dann. Und wenn das halt automatisch
alles da wäre, wäre natürlich schon nett.
Ja.
Genau.
Ansonsten, tja, ich weiß nicht.
CSS haben
Tja.
Ich muss mich damit mal auseinandersetzen.
Ich komme nicht mehr drum rum.
Das erzählst du mir schon seit Jahren.
Seit Jahren.
Und dann habe ich doch immer wieder was anderes gefunden.
Ja.
Ja, es ist...
Es lässt sich aber, glaube ich, inzwischen echt nicht mehr vermeiden.
Ja, wie zum bisschen. Also deswegen
empfehlen wir immer noch Tailwind.
Hast du das schon gesagt?
Ich bin ein kleiner Fan davon.
Es war so ein bisschen...
Ich konnte CSS sehr, sehr lange überhaupt nicht leiden.
und es war irgendwie mega hässlich.
Und dann fühlte sich es so an,
wie ich es machen will. Das ist so wie bei Python,
wo ich relativ schnell wusste,
okay, so will ich es machen.
Ja. Das ist immer dann, wenn man
gar nicht weiß, wie es geht und dann findet man was,
was irgendwie cool ist. Ich weiß auch nicht.
Vielleicht ist man auch völlig auf dem Holzweg, weil man keinen hat,
der einem erklärt hat, wie es richtig ist. Aber vielleicht ist es auch
manchmal gar nicht so schlecht, wenn man da so ein bisschen seiner Intuition folgt.
Ja, am besten
ist es wahrscheinlich, man muss irgendwas machen und dann
schauen, ob man
den Kurs korrigiert, wenn es irgendwie nicht mehr gut
gut. Ja, das sollte schon
möglich sein, dass man seine Meinung auch wechseln
kann. Das ist, glaube ich, schon...
Wir werden
uns weiter
Dinge angucken und dann sagen wir
Bescheid, wenn wir irgendwie das perfekt gefunden haben.
Ansonsten, ja,
ich meine, keine Ahnung, ich könnte ein bisschen was erzählen
zu den Sachen, die ich so mache. Warum gucke ich
mir eigentlich CSS-Geschichten an?
Ja, erzähl mal, warum guckst du dir CSS-Geschichten an? Ist ja langweilig.
Jochen hat schon was zu tun.
Ja, ich habe ja diverse
Projekte, ja.
aber
genau, momentan
also eine Geschichte, die ganz
interessant ist, also HTMLX
das beeinflusst halt
so viele Sachen, weil das halt
mit HTMLX sagen wir die nächsten Trinkspiele, Jochen
wenn ich das sage, was
ja, stimmt schon
aber, naja, so
weil vieles
so gerade, ich hatte mal irgendwann vor Jahren
also das ist zum Beispiel wieder eins von diesen Beispielen
so ein Bookmarking
angefangen und das macht halt auch so viel
mit Bootstrap
und so und jQuery
und ist halt alles ziemlich hässlich,
was Frontend-Geschichten angeht.
das im letzten Moment angefasst,
wieder auf aktuellen Stand gebracht und
da könnte man wahrscheinlich mit HTML
sehr viel machen und dann ist halt die Frage,
kann man dann nicht den ganzen anderen Kram gleich mit
rausschmeißen, also sowas wie dieses ganze
jQuery-Graffel und irgendwie
Bootstrap und so, das wäre doch eigentlich ganz nett.
Und dann ist halt die Frage, okay, was macht man in der Hand?
was sind denn deine CSS?
Genau, genau.
Weil genau, perfekt,
dann ist auch dafür auch super geeignet.
Du hast ein Snippet,
das du per HTMLX rausrennen kannst
und was schreibst du in dein Snippet rein?
Ja, genau,
also das wäre natürlich nett,
das sind halt so Sachen,
die Tailwind-Blend machen,
ist halt,
dass es,
wenn es im HTML-Strom steht,
dann kann man es eben auch direkt mit,
man muss halt nicht
ein neues CSS mit ausliefern.
Genau,
und du musst auch nicht jedes Mal
in das,
irgendein großes CSS,
in das du schon ausgeliefert hast,
genau die Sachen reintreiben,
sondern schreibst halt genau das,
was du willst,
in dein,
ja.
Aber du hast eben auch gesagt, also ja, also die großen Designer, die sich die ganz tollen Konzepte überlegt haben mit ihren Style Guides, die könnten eventuell sagen, dass du dann einfach trotzdem den Button kleiner machst, obwohl das verboten ist im Style Guide.
Ja, ich weiß, ich habe ehrlich gesagt
keine Ahnung, wie man das alles wirklich macht, aber naja
Ja, aber genau
das wäre so
das war so einer der Gründe, warum ich da nochmal drüber nachgedacht habe
dann genau
war auch sowas wie
ja
diese, dafür würde ich gerne
so eine Landingpage bauen, halt irgendwie
Podcast-Hosting
Service-Geschichte
und da braucht man dann ja auch vielleicht ein bisschen
mehr Design-Wumms und dann
Es bootstrapft vielleicht irgendwie nicht das Richtige.
Also was wir da machen, ist
Designer fragen.
Dann machen die uns einen Entwurf,
Design. Und dann machen wir das
in Tablet.
Ja, irgendwie
sowas.
Da helfe ich dir gerne bei.
Du hast noch ein paar Sachen entdeckt, ein paar Pics fast.
Ja, aber genau.
Kann man auch einfach mal raushauen.
Gibt es ja genug Gelegenheiten für andere Pics.
Mermaid. Mermaid habe ich jetzt
letztens gesehen.
ziemlich coole Sache, das kann ich noch nicht.
Was man damit machen kann, ist Markdown-Enhance
um sowas wie Diagramme.
Ja, genau. Und das kann halt
auch diese Diagramme, die Arten von Diagrammen,
die man halt... Also das, was
ihr von Draw.io vielleicht kennt so ein bisschen oder so.
Wenn ihr so, weiß nicht, ob das in der Komplexität
geht, aber richtig coole Sachen,
die man echt gut dastehen kann.
EM-Diagramme, Flowcharts,
sowas. Einfach als Markdown
schreiben, so ein bisschen runterschreiben und dann könnt
ihr das auch direkt rennern lassen. Auch von
sowas wie GitHub. Ja, also
und
mit Graphics oder Dot irgendwie hat das
dann gerendert, aber das ist alles
nicht so...
Also für das ERM, die Rahmen direkt rausrennen lassen
aus den Models, ist das natürlich schon nett. Also wir reden ja
gerade über Mermaid, dass das glaube ich nicht macht.
Nee, da machst du es von Hand, aber da hast du halt dann auch mehr
Kontrollmöglichkeiten. Also insofern...
Ja gut, aber ich will jetzt natürlich nicht jetzt irgendwie,
wenn irgendjemand einfach kurz das ERM sehen will,
dann explotiere ich halt einfach aus meinen Dango-Models.
Aber ja, du hast natürlich recht.
Viel schöner, wenn man das vorbereitet und am Anfang,
bevor man die Models hat, kann man das
ja vielleicht bauen so.
Naja, ist eher so, weil die Frage ist, was willst du in deiner Dokumentation verlinken?
Und ein automatisch
generiertes Ding in der Dokumentation ist halt
irgendwie nicht so
super. Die wichtigere Frage wäre, liest jemand
die Dokumentation?
Ja, das ist auch, vielleicht nicht.
Ja, wenn nicht, dann mache ich es automatisch, weil
dann muss ich ja keine Arbeitszeit reinstecken. Wenn doch,
dann sollte man es ordentlich machen. Aber das ist immer ein bisschen
die Frage, weil einige Leute wollen die unbedingt haben,
aber niemand guckt rein.
Dann ist es halt nur für einen selber und dann weiß ich nicht,
ob ich das dann...
Ja, aber, also was mich halt freut, ist, dass es jetzt auf jeden Fall ein Ding gibt, wo man, also sonst habe ich mich immer gefragt, ja, nehme ich Draw.io oder nehme ich irgendein anderes Tool oder nehme ich halt irgendwie irgendein Desktop-Ding, was ich halt habe und dann mache ich das als PNG raus oder als SVG, nehme ich lieber ein SVG oder weiß nicht so genau und dann, das sieht aber auch wieder ganz anders aus als alle anderen Diagramme, die ich sonst so gemacht habe, also Mist auf dem Hintergrund funktioniert das aber nicht, halt diese ganzen Probleme und das ist dann halt alles los, wenn man das mit Mermaid macht.
Ja, also das ist wie gesagt Master und ihr könnt auch sowas machen wie verschiedene Projekte, wie lange wollt ihr die ins Kedulen und dann nebeneinander, das finde ich echt sehr cool, also ich muss mir das unbedingt angucken, weil ich halt diese Tasks, die hintereinander kommen, wie lange brauchen die denn, kannst du so ein Ad-Gent oder sowas für verschiedene Projekte bauen kann in Markdown und wir benutzen ja eh für alles jetzt Markdown, nicht wahr Jochen?
Ja, ich weiß nicht so genau.
Nein, zum Schreiben, nicht?
Ja, meistens, also
genau, ich habe jetzt auch
MPDocs mehr dann angeguckt und damit geht das halt auch
da gibt es so ein Plugin für
Data-Templates geht auch
PDF geht, sogar
so Richtung Latex-Templates geht
es geht, was noch?
Was brauchen wir noch? PDF natürlich, aber
Präsentationen geht
Naja, oder Notebooks verwende ich halt auch
Markdown viel
Klar, aber
sagen wir mal so, also für Python-Dokumentation
traditionell verwenden Leute ja dann
Restructured Text. Ja, aber das ist so hässlich.
Ja, es ist hässlich, aber
es kann halt viel mehr als Markdown.
Und es gibt halt, die Leute sagen halt
immer so, ja, also Markdown
nett, aber es kann halt nicht die Sachen, die ich brauche.
Daher nehme ich lieber, also gerade was
Links angeht und so,
daher nehme ich lieber Restructured Text.
Ich glaube auch, das ist immer noch
das, was am häufigsten verwendet wird.
Also wenn man irgendwie Dokumentationen von Projekten anguckt,
dann ist es meistens Restructured Text.
Aber ich hatte auch öfter mal Restructured Text mit Trinks oder so.
Ja.
versucht, aber...
Ich verstehe,
wo das Problem ist, ja.
Also es schlägt dann keiner mehr. Also Markdown kann man irgendwie
besser...
Ich weiß nicht, Research-Dischekt wird es nicht schaffen.
Keine Ahnung, aber...
Bin ich mir sicher. Also Markdown kann man so
super viele Anwendungsfelder haben. Man kann das halt einfach
sein GitHub hochladen, es ist direkt gerendert.
Man kann, weiß nicht, es gibt so Typora oder so,
ich glaube, der ist leider, der war tischendurch frei,
ich glaube, der ist jetzt leider auch
proprietär, aber
da konnte man wie so ein Schreibprogramm
seine Eltern überreden, wenn die
irgendwas schreiben wollen und kein Word brauchen, hey, schreib doch
Depora, dann hat die Markdown-Files voll toll.
Und die haben es gar nicht gemerkt, weil das so ein Wolf-Misky-Editor
für Markdown hat das. Richtig schön.
Und so war es halt. Und ja,
Obsidian vielleicht noch.
Und das halt so eine grafische Visualisierung
von deinen Markdowns macht, wenn du das
möchtest. Und dann kannst du so ein bisschen sehen, woran du arbeitest.
Oder wie die Themen untereinander verknüpft sind. Die Links können
man... Kennst du das Zettelkasten-
Prinzip?
Äh, Luhmann ist das
irgendwie, ne? Oder... Ich weiß nicht genau,
wie heißt?
Ach, jetzt können wir es nicht erklären.
Jetzt müssen wir
ein eigenes Amt hier haben.
Doch, ich glaube,
du kannst auf jeden Fall Sachen da richtig
einsortieren und hast durch die Verknüpfung direkt
viel schnellere Sachbehalte
miteinander gebündelt.
Ja.
Ja, Luhmann kann sein, dass das richtig war, aber
wie genau das ging, weiß ich jetzt nicht genau.
Jedenfalls unterstützt
auch das deine Ablage an dieser
Methoden.
Mein Notizblock SimpleNode, ich muss
auch Markdown, Vendable und so.
Ja, also es gibt ganz viele Kleinigkeiten,
die in diese Markdown-Welt reinspielen und diese
schlimmste sind alle Interchangeable
und das ist, also ich bin auch ein großer
Fan von Markdown, habe ich ja schon gesagt.
Nee, aber ich glaube, man kann das irgendwie
durchaus so raushören, wenn man da
ganz, ganz genau mit der Lupe
draufkommt.
Ja.
Ja,
ja, es läuft
momentan alles ein bisschen auf Markdown hinaus.
mal schauen.
Genau, auch schön ist, dass es halt auch in GitHub-Geschichten
funktioniert, dass es auch irgendwie Standard-
Integration, Standard-Message-Integration
an, das heißt, wenn man das einfach so reinschreibt, dann
hat man das halt auch in Issues oder halt in
irgendwie, ja, Markdown, was halt
auch von GitHub gerendert wird.
Ja, überhaupt
aber das ganze Dokumentationsthema
ist ja auch so, in letzter Zeit habe ich mich
ein bisschen
mit MakeDocs
beschäftigt, aber halt
auch überhaupt mit diesem Ding, dass man das
halt vielleicht mal tun sollte, weil
also meine Ansicht dazu bisher war ja eigentlich
immer so Dokumentation, ah ne, lieber nicht.
Ist ein bisschen
zweifelhaft vielleicht und
inzwischen denke ich mir so,
naja, vielleicht ist es doch nicht so schlau.
Und genau,
da hatte Simon Willison
auch irgendwie diverse Artikel jetzt
in letzter Zeit in seinem Blog einmal
irgendwie bessere Release Notes
schreiben. Da versuche ich mich
jetzt auch so ein bisschen dran zu halten.
Ja, das finde ich schwierig. Also bei mir steht auch
in den meisten Commits nur Schrott drin wie
FixedSomething oder FixedFinal
oder FixedAgain oder Typo.
Ja, also ich versuche es immer. Also es gibt dann immer
einen Commit, der ist ordentlich
und 15 dann, die sind irgendwie
so Fixes davon. Ich glaube, man kann die irgendwie
stacken.
Du kannst sie hinterher
squashen, wenn du das halt
in einem Pull-Request zusammenfasst.
Ja, aber das mache ich zum Beispiel nicht.
Ja? Ja, das würde man in Pull-Requests
machen. Das ist bei mir relativ egal,
wenn ich der Einzige bin, der auf so einem Branch ackert, dann ist das
für dich burschen. Ja, klar, klar.
Ja, würde ich auch sagen. Also normalerweise
irgendwie mache ich das halt auch nicht, wenn ich da
irgendwie alleine... Aber wenn man sich jetzt überlegt,
eigentlich möchte man ja vielleicht
irgendwie die Entwicklung auch skalieren können.
Ja, das ist sehr sinnvoll,
dass man gute
Commit-Messages hat, wo auch was passiert
und nicht nur zwei Leerzeichen gemittet werden. Dann müsste man
auf jeden Fall seine Commits alles squashen
und die ordentlich machen und so Aber so Commit ist jetzt bei mir so die gehen eigentlich finde ich Die sind gar nicht so schlimm Aber die sind auch ganz okay Ich habe mich ja mal die Zeit mit euch
unterhalten. Das ist auch schon ein paar
Jährchen her, glaube ich. Und zwar, ob man die in Präsenz
oder in der
Vergangenheitsform formuliert.
Ja.
Weiß ich auch gar nicht mehr. Das Ergebnis war, Präsenz wurde
bevorzugt. Präsenz, ja, kann sein.
Ich weiß jetzt gar nicht, was ich...
Dieser Comment-Trick ist dissonierend, anstatt dieser
hat das gefixt.
Ja.
Aber das ist ja nicht das gleiche wie Release Logs.
Release Logs ist nochmal eine andere Geschichte.
Ja, aber wann macht man das zum Beispiel?
Wann schreibt man quasi sein...
Ja.
Die Fixliste.
Wenn du
eine Release machst.
Ja, aber auf Semantic Version,
auf welcher...
Semantic Version ist halt eine Sache.
Braucht man das? Nein?
Warum nicht?
Naja, weil es ja auch nicht wirklich hilft
und also gut, auch da gibt es
eine Menge Leute, die mittlerweile
halt irgendwie einfach
fortlaufende Geschichten machen.
Ein bisschen Pseudo ist ja ganz okay.
Wenn man zum Beispiel weiß, man hat jetzt nur ein bisschen was
gefixt oder arbeitet an so ein paar
Sachen rum, dann macht man
immer so die Patch-Version.
Wenn man jetzt quasi ein paar neue Features eingebaut hat, würde ich
sagen, schon Miner nach oben.
Machen wir einfach Miner einen hoch. Neue Features,
Miner.
Und Mater ist Breaking Change, also es geht irgendwas
nicht mehr mit früher, dann ist es major.
Ja, wenn man das so machen will,
klar, aber die Frage ist halt,
ob das jetzt sinnvoll ist oder nicht, das ist halt nochmal
eine andere Frage. Es gibt Leute, die machen es so, machen es anders.
Aber egal, wie man es macht,
also Release Notes zu schreiben,
ist wahrscheinlich immer eine ganz gute Idee, egal, wie man es
macht.
Und auch da ein Datum zum Beispiel dazu
zu schreiben und dann halt noch, da kann man sich
auch die Artikel mal im Detail angucken.
Ja, stimmt, sollte man machen.
Idealerweise sollte da die User-Story beschrieben sein,
die gefixt wurde oder die dazugekommen ist.
ist auch nicht gut. Es sollte
so sein, dass...
Ein Satz zu dem Punkt.
Ein Satz, okay, das ist okay,
aber es sollte halt nicht irgendwie, genau.
Man kann ja durchaus die Issues
und so reinschreiben.
Der User kann sich jetzt
auf unserem Backend einloggen.
Oder sowas wie, der User
kann jetzt den Filter
so bedienen, dass er alle möglichen...
Das ist halt die Frage, für wen schreibst du das?
Das sollte man sich vielleicht auch überlegen.
und die Devs.
Ja, aber die interessiert das doch nicht, was die User-Story ist.
Also ich würde sagen, aus einer technischen Perspektive
sind die User-Stories doch eigentlich komplett uninteressant.
Ja, aber das wäre die technische Formulierung von
du kannst jetzt in diesem Formular das und das, die Auswahlfehler.
Also technisch würde ich reinschreiben, was tatsächlich passiert ist,
was man geändert hat.
Oder so, die Cop-Messages aneinander kleben.
Nee, nee, nicht die,
aber halt sozusagen reinschreiben,
was da passiert ist.
Aber aus Business-Sicht ist das halt uninteressant.
Aus Business-Sicht ist halt nur interessant,
was ist denn jetzt mit unseren User-Stories passiert.
aber aus technischer Sicht sind die User-Stories halt relativ irrelevant.
Das finde ich gar nicht.
Ne? Okay, gut. Interessant.
Ich weiß es nicht so genau.
Ich würde sagen, dass die meisten Open-Source-Projekte
sowas gar nicht haben. Die haben gar keine User-Stories oder sowas.
Ja, okay, aber
das, was damit gemeint ist, weil tatsächlich ja das Feature,
das man baut, vielleicht das ist, was man dann umsetzt
und wie man das, also das würde ich jetzt
in den Release-Log reintreiben, welches Feature jetzt
umgesetzt ist.
Ja, wie gesagt, aber ich glaube,
es würde wahrscheinlich schon viel helfen, wenn man sich
überlegt, an wen richtet sich das eigentlich?
Wer soll das lesen?
Kann man ja zu unterschiedlichen Ergebnissen kommen.
Kann man zu unterschiedlichen Ergebnissen kommen.
Nutzer lesen oder die Devs lesen.
Und zum Beispiel
ein Ding, das mich jetzt gerade interessiert,
deswegen beschäftige ich mich damit auch so ein bisschen,
wenn man jetzt Entwicklung skalieren möchte,
dann
ist es vielleicht gar nicht so schlecht,
zum Beispiel eben auch andere Artikel,
ich weiß jetzt gar nicht mehr, wie der Titel von dem war,
hat er so, ja, also
er schreibt immer, seit einiger Zeit
und macht er immer GitHub-Issues auf für alles, was er macht.
Und einfach, um halt einen Punkt zu haben, wo er alles sammeln kann,
was zu einem bestimmten Ding gehört.
Und zwar nicht nur...
Was ich ganz gerne mache, das muss man halt immer ein bisschen einstellen,
ist To-Do-Kommentare im Code.
Aber die mit GitHub-Post-Assessing, dass ihr einen Hook habt,
dass ihr automatisch aus meinen To-Dos im Code Issues erstellt,
auf GitHub und die automatisch wieder zumacht,
wenn das To-Do da verschwindet und das CD
automatisch auch nummeriert und das dann halt auch in dem
Commit mit ergänzt.
Das heißt, er schreibt dann quasi an den To-Do die
Issue-Nummer mit dran und
dann kann man quasi darüber auch direkt sich linken
lassen, wenn man das einstellt, auf den Issue
auf GitHub und sich den angucken und die Diskussion dazu angucken
und hat aber das im Code stehen und muss halt
nicht zwei Sachen pflegen, sondern du kannst halt einfach im Code
das dann bereinigen
und dann ist halt geschlossen
und sowas. Und das finde ich
sehr gut.
Ja, wenn du eine Stelle hast an einem Code, wo du das hin...
Aber es gibt ja auch viele Dinge, die sind...
Kannst ja nicht an einer Stelle festmachen.
Aber gut, ja.
Wie man es macht, ist ja letztlich...
Du kannst natürlich auch ein extra machen und dann halt referenzieren.
In einem Commit oder so. Aber, ja.
Genau, und das kannst du ja mit dem
Issue auch super machen. GitHub macht das ja gut.
Also es erinnert dich niemand daran, noch extra Issues aufzumachen,
wollte ich da mal sagen.
Ja, ja. Nee, klar.
Ich weiß gar nicht...
Wie man es jetzt macht, das kann man
halt machen, wie man will.
aber was ich daran interessant fand
ist halt, also einmal sagt er halt
warum er das macht
ist halt, dass er einen Punkt haben möchte
sozusagen
an dem alles andere hängt
und GitHub macht das ja automatisch für ihn
das alles zusammenzuführen, wenn er irgendwo dann halt
die Issue-Nummer mit reinschreibt
und
der andere Punkt ist halt
er hätte gerne dann daraus einen Pull-Request
und dann sozusagen einen perfekten Commit
der halt das dann halt irgendwie handelt
wo er dann halt
sozusagen alles zusammen hat, was
Änderungen an Dokumentation,
Test, Code gemacht werden muss,
damit das halt irgendwie dann,
damit er das Ding zumachen kann.
Und
dann ist der
Issue sozusagen eigentlich auch so eine schöne
Geschichte, um halt
da reinzuschreiben, was dann
überhaupt passieren soll. Auch eine gute Gelegenheit,
um sich Gedanken zu machen, was man eigentlich machen will.
Und allein, wenn man sich
überlegt, okay, ich mache jetzt ein Issue auf und schreibe mir erstmal auf,
was denn jetzt dazugehört, dann
erledigen sich halt viele Sachen schon, weil man dann anfängt,
so ein bisschen gezwungen ist, darüber nochmal nachzudenken
und dann vieles sich dann auch schon wieder erledigt.
Wenn man so anfängt nachzudenken, ist ja manchmal so ein bisschen
nicht so
schlecht. Oft ist es halt so, dass
man das dann später merkt, wenn man irgendwie anfängt zu entwickeln
und dann später merkt man so, oh, das hätte ich jetzt alles
eigentlich gar nicht machen müssen. Aber
also, das
fand ich ganz nett.
Vor allen Dingen, ich habe das jetzt zum Beispiel
für einen Ding, ich habe so einen Podcast klein geschrieben.
Ich weiß nicht genau, warum ich das jetzt gemacht habe.
Wahrscheinlich.
für diesen Ding, Jagni.
Ich weiß nicht genau, wo ich den noch gemacht habe.
Ja, Jagni könnte sein.
Oder halt auch einfach
so Standard-Jag-Shaving
könnte auch gut sein.
Ja, eben.
Ich kann mir vielleicht gleich nochmal eine Abschweife
nicht so unternehmen.
Aber genau.
Und da habe ich mir dann gedacht,
okay, das war dann halt auch das Richtige.
Das mit den Issues mache ich jetzt vielleicht auch mal so.
Ich lege einfach schon mal ein paar Issues an.
Wenn jemand vorbeikommt und da drauf guckt,
dann kann er das vielleicht einfach so machen.
einfach, damit Leute halt einen Ansatzpunkt haben.
Wenn du halt einfach so eine Code-Basis hast, dann weißt du ja gar nicht,
selbst wenn du dann irgendwas machen wollen würdest,
was du dir jetzt da machen sollst.
Die meisten Leute, die gehen ja nicht hin und gucken,
oh, was gibt es denn schon für Git-Apps für coole
Podcast-Clients? Oh, der ist auch total unfertig,
das sieht doch cool aus, da gucke ich mir in die Intuos rein,
was ich alles machen kann.
Sondern die fangen dann ihren eigenen Podcast-Client an.
Ja, so wie ich, das stimmt.
Ja, genau.
Vielleicht ist es ein bisschen zu enthusiastisch,
optimistisch
verblendet.
aber
wenn man das denn machen wollen
würde, dann ist es natürlich die Wahrscheinlichkeit,
dass jemand vorbeikommt und was macht, vielleicht viel höher,
wenn da schon sowas ist. Ja, ich würde sagen,
das macht tatsächlich dann Sinn, wenn das Projekt schon so ein
bisschen Drive aufgenommen hat,
ein paar Stars gesammelt hat und man dann
denkt so, hey, es wäre jetzt vielleicht cool, so ein paar
Nee, ich mache das vor allen Dingen
deswegen halt auch, um das zu üben, weil
wenn man es dann braucht, dann ist es ja
immer schlecht. Wenn man das dann erst lernt.
Genau. Man muss ja immer schon alles direkt perfekt
können. Nicht perfekt, aber so ein bisschen besser als wie man vergrattert.
Also perfekt.
Ja, es ist manchmal nicht so einfach.
Ja, also immer auf jeden Fall besser als alle.
Ja, ja, ich verstehe das.
Ah, ja.
Ja, das ist halt aber tatsächlich so eins der Probleme, die wir in unserer Gesellschaft
und unserer Kultur haben. Das sehen andere Leute aus anderen Ländern überhaupt nicht
so. Die verstehen das überhaupt nicht, warum wir da so völlig bescheuert sind.
Und denen ist das, also die können das wirklich nicht anbeziehen.
Ich finde das auch ein bisschen anstrengend immer.
und ich finde das auch nicht so produktiv
und es ist tatsächlich nicht so
Business-optimiert.
Ja, das mag sein.
Aber zu Glück muss ich auch nicht auf Business-Ziele
optimieren.
Ja, gut für dich, Jochen.
Ja, genau.
Ich wollte einfach mal ein bisschen
Übungen zu schreiben und
ja, das mache ich jetzt auch so ein bisschen.
Und tatsächlich, ich finde eigentlich
Podcast-Client ist, also habe ich schon erzählt, warum ich das
interessant finde oder was mich da so dran angesprungen hat.
Der Grund, warum ich das mache, ist, dass man das ja sowieso irgendwie braucht. Ich habe das Gefühl, ich muss es sowieso früher oder später irgendwann tun. Und der Grund, warum ich das tun muss, ist, weil da ja so viele schöne andere Dinge dranhängen, wie zum Beispiel, wenn du jetzt wissen möchtest, wie zum Beispiel ein Podcast aussieht in einem Podcast-Rosting.
Dann willst du den vielleicht importieren
Wie machst du das? Naja, du sagst halt, hier ist mein Feed
Importier doch mal
Feed importieren irgendwo her
und einen Client haben, der irgendwie sagt
Das ist fast das gleiche
Ja, fast
Und überhaupt
Vielleicht willst du einen Katalog haben
Da musst du auch die
Dinger parsen können
Podcast Client haben ist fast das gleiche
Ganz interessante Geschichte und dann wollte ich mal gucken
und Jochen unterhalten sich über die Programmiersprache Python
verwendet habe, ist Butt.
Das verwende ich auch immer noch. Ich finde das super.
Ja, so ist es. Das ist auch ganz gut.
Fast, Modern Unix.
Ja, aber bei mir
man kann es konfigurieren,
aber in der Default-Konfiguration macht es halt
irgendwie Zeilennummern davor. Ja, das kann man nicht mehr
copy und pasten, hast du recht. Das heißt, da kann man auch nicht mehr
pipen, wie man das mit Cut gewohnt ist. Und deswegen
muss man die Konfiguration anpassen. Das sind zwei
Environment Variables, die man testen muss.
Und dann muss man machen,
was man haben möchte.
Also eine für den Style und eine für die Teilnummern
und dann kann man das nach wie vor in einen Pipes einsetzen und kann das dann alias auch auf Cut und dann kann man Butt nehmen für Mitzeichnungen.
Ja, aber wie gesagt, wenn man
Rich nimmt, dann ist das halt, also Rich CLI und auf der Kommandozeile ist es dann einfach nur
Rich, dann muss man das eben nicht machen, sondern es funktioniert einfach so.
Und es kann auch ein bisschen mehr syntax-highlighting-Geschichten machen als Butt.
Also insofern, ja, kann man ja mal ausprobieren.
Also ich mag ja Rich auch, ich mache mit Rich auch
Konsolenanwendung teilweise.
Ja, gibt es jetzt auch.
Nein, das sage ich jetzt nicht.
Da müsst ihr jetzt warten
bis zum Schluss, dann picke ich nämlich das
stattdessen.
Und genau.
Da dachte ich, so kommen halt ein paar
Sachen zusammen, die das aus unterschiedlichen
Gesichtspunkten interessant machen. Deswegen habe ich damit mal
angefangen.
Ich habe, genau, also
eine der Geschichten von diesem Bootstrap-Ding
und Jungle-Crispy-Forms und so muss man irgendwie weg.
Ich habe jetzt auch, das habe ich relativ
aus anderen Gründen
und dann das jetzt nicht mehr in der privaten
Praxis viel mehr zu tun gehabt.
Es gibt auch irgendein, ich weiß nicht mehr,
ob das mit Crispyforms war oder sowas,
wo man einen Hook reinbauen kann
und dann halt die Forms mit Tailwind benutzen kann.
Ja, also ich würde sagen,
das wäre auch interessant, wenn da jemand
Empfehlungen zu hat.
Crispyform habe ich auch immer so verwendet. Ich habe es nie so genau
angeguckt, sondern immer nur so benutzt.
Und es hat ja einige ganz nette
Geschichten und es macht einige Dinge ja
einfacher. Und jetzt habe ich da so mal tief reingeguckt und ich muss sagen, das muss alles weg.
Das geht nicht. Das ist alles
ganz schrecklich. Also das ist halt irgendwie langsam.
Man kriegt es auch nicht schnell, weil es ist furchtbar. Und das ist
alles so. Also das ist, nee. Also ich
denke, man sollte das anders machen. Ich weiß jetzt auch noch nicht wie, aber man muss das irgendwie
anders machen. Das geht so nicht. Und das war mir nicht so klar vorher, als ich
noch nicht reingeguckt hat.
Das hätte ich auch schon nehmen.
Irgendwas mit Forms muss man sich nochmal ausdenken.
Ja, wobei,
das ist halt das Problem.
Ich meine,
wenn du das jetzt so machst,
dass du die CSS-Klassen in HTML setzt und so,
dann hast du halt beim Rendern ein Problem,
weil dann musst du das nämlich alles irgendwie setzen.
Wieso? Du machst ein Template für einen...
Ja, weil
das ist ja genau das Problem, das CrispyForms löst.
Du hast halt eine Form,
jetzt kommen die Formfehler zurück,
wie machst du das so, dass
jetzt deine Fehler ordentlich, dass da so ein roter
Klingel drumrum ist?
Ja, du benutzt den Default, den machst du zum Beispiel mit
Crispy Template, Crispy Table gibt es auch
und dann, also ich kann nicht sagen,
dass das auch langsam ist, weil das auch Crispy Form ist,
aber dann machst du halt einfach
in deinem Template, überschreibst dann halt den Default
und hast dann
einen schönen Style.
Du musst es ja in das HTML rausrendern, weil die Klassen müssen ja im HTML drin sein.
Das wird dann da reingeredert,
wenn du einfach deine Form erzeugst und die Form
gibt es im Flanko View.
Also wie passiert das denn zum Beispiel, wenn da halt die Fehler zurückgegeben werden?
Du hast jetzt eine Form, jetzt validiert das nicht, sondern das sind irgendwie Fehler.
Dann nimmt dir die Fehlerklasse und in der Fehlerklasse hängt ein HTML-Element mit dran.
Ja, aber das ist nicht einfach irgendwie eine Fehlerklasse.
Doch, das ist doch...
Da wird ganz kompliziertes Zeug gemacht.
Da werden diverse Klassen hinzugefügt, diverse Sachen geändert.
Und das musst du auch machen, sonst geht das nicht gut aus hinterher.
Ja, aber du kannst ja überschreiben, glaube ich.
Ich hatte aber irgendwie mal ein, zwei Sachen
customised, ging. Ja, man kann so ein bisschen
customisen, aber naja, okay, keine Ahnung.
Also wie gesagt, dieses Problem hast du,
wenn du das HTML verändern
musst, wenn du jetzt einen Fehler rennst.
Dann musst du das irgendwie machen, wie auch immer
du das machst, aber du musst es ja irgendwie tun.
Und das ist nicht so, dass da irgendwas in Django drin wäre, was dir
dabei hilft, sondern da musst du halt dann irgendwie
Crispy Forms nehmen oder irgendwas anderes, was das halt für dich
macht. Und das ist halt nicht so
ganz einfach. Während wenn du jetzt, sagen wir so,
und Jochen unterhalten sich über die Programmiersprache Python
und zahlst du das in einem CSS und fertig.
Das macht es dann halt
deutlich einfacher. Aber ich weiß es noch nicht.
Ich muss mal gucken. Ich habe keine Ahnung.
Ich werde mich damit mal beschäftigen.
Da muss man so ein Template wieder bauen für
HTMLX und Django.
Also eine Geschichte
ist halt, ich weiß nicht,
SQL Model, sagt ihr ja.
Es gab jetzt auch letztens eine Episode
zu irgendwie wieder auf
TalkPython2Me.
Und das versuche ich ja gerade zu entfernen.
Zum Beispiel aus
aus dem
Fast Deploy.
Und der Grund ist,
weshalb ich das versuche zu machen,
ist, dass ich
versuche, mal das so ein bisschen
umzuorganisieren.
Dass halt so ein bisschen Software-Architektur
reinkommt. Ich weiß, das ist auch nicht ohne Gittermann Sache.
Ich habe auch früher mal schon gedacht,
Software-Architektur.
Das schnürt mir schon, wenn ich das Wort ausspreche,
irgendwie die Krawatte, die Luft ab.
Als Architekt.
Ein feiner Herr.
Ja, geil. Aber
vielleicht gibt es Situationen, in denen das doch nicht so
verkehrt ist und ich wollte es einfach mal so ein bisschen
ausprobieren und deswegen mache ich das da jetzt
und genau,
da ist ja immer so...
Was ist denn Architektur, Softwarearchitektur überhaupt?
Naja, es ist im Wesentlichen
quasi die Beschreibung
für die Tätigkeit, die man halt
ausübt, wenn man
Software versucht zu modularisieren, also
so in Teile zu zerlegen, dass man nur noch
irgendwie, dass die
Gesamtkomplexität nur noch
dominiert wird von der Komplexität des kompliziertesten, komplexesten
Moduls und nicht mehr alles mit allem zusammenhängt.
Und die Art, was man macht, wenn man das jetzt tut und versucht, das klein zu hauen,
das nennt man Softwarearchitektur, sage ich jetzt mal so.
Das wäre jetzt meine aus der hohlen Hand Definition. Es gibt da Leute, die versucht haben,
das ernsthaft zu definieren, wie so Martin Fowler und so, die würden sowas sagen wie
Softwarearchitektur sind alle die
grundlegenden und schwer änderbaren Entscheidungen, die
ich weiß nicht, ob ich die Definition richtig zusammenkriege,
die Einfluss dann halt auf das Projekt haben und die dazu führen,
ob man jetzt irgendwie Dinge schneller ändern kann oder nicht. Kann man auch kritisieren,
es ist so wichtig, ob man Code hinterher ändern kann oder nicht,
was sind das denn eigentlich, wenn man weiß, dass es wichtig ist, dann hat man ja schon den Teil der
Softwarearchitektur irgendwie erledigt im Grunde, man weiß halt vor allem bei den Entscheidungen halt dummerweise
leider vorher meistens nie, ob die jetzt wichtig sind
oder nicht. Aber das ist halt
eine Definition. Ich glaube, ich habe die von,
die haben auch andere Leute so ähnlich
auch schon gebracht.
Mir gefällt
die, irgendwie, wie zerlegt man
eigentlich ein Programm in kleinere Teile
ein bisschen besser.
Aber, ja gut, ist halt
ein bisschen schmackser. Aber im Grunde irgendwie so,
man kann sich das auch vorstellen, ja, wie wenn man ein Haus
da Eisvektor hat, dann kann man auch für ein Software-Ding
Eisvektor haben. Also Microsoft
ist das für so Häuser breitstellen. Also
auf seinem eigenen.
Microservices wäre halt ein
Ding, wie man, also aber Architektur
bezieht sich jetzt nicht auf
den IT-Teil, nicht auf das System,
sondern
eher auf die Software. Also
du kannst natürlich auch, ich meine, das sind halt
eher so die Dinge, wo ich das Gefühl habe, das geht dann halt schief.
Wenn Leute
das Software-Problem,
weil sie es irgendwie nicht lösen können,
das sieht man übrigens ganz oft, also
mir begegnet das häufig und es ist
furchtbar.
meistens, also die Konsequenzen sind meistens
furchtbar,
dass Leute halt diese Modularisierungsding
in der Software nicht gebacken kriegen, aus welchen Gründen
auch immer, und dann
hingehen und das versuchen auf einer anderen Ebene
zu lösen. Also auf der Ebene zum Beispiel, was man
häufig sieht, ist, dass die Leute dann versuchen, das organisatorisch
zu lösen, oder dass Leute versuchen, es mit
IT-Geschichten zu lösen,
irgendwie, wir nehmen jetzt die Cloud, oder
dass Leute es mit Microservices
versuchen, und all diese
Ansätze sind eigentlich immer, das scheitert immer ganz schräg.
ganz spektakulär, weil
an dem grundsätzlichen Problem
ändert sich dadurch nichts und du hast dir das Leben
halt irgendwie gerade nochmal
in Größenordnung schwerer gemacht, dadurch, dass du jetzt
zum Beispiel...
Ein Park, ein Fuhrpark,
ein Zoo...
Ja, gerade Microservice gab es auch
letztens, habe ich auch letztens in einem Podcast
darüber gehört, es gibt
ein Buch, das irgendwie alle immer referenzieren, was
Microservice angeht
und der
sprach dann halt auch so drüber,
der hat das Buch geschrieben und meinte so, ich bin ein bisschen
unglücklich, ich gelte jetzt immer als der Experte für Microservices,
jetzt, weil ich dieses Buch geschrieben habe, na gut.
Und der meinte,
er macht halt viel Consulting irgendwie und
wird eigentlich immer dazu gerufen, wenn irgendwelche
Leute auf die Idee gekommen sind, wir müssen jetzt mal auf
Microsoft-Architektur umsteigen.
Und dann holt man sich halt irgendjemanden dazu, der dann
sagen soll, warum das irgendwie alles eine super Idee war.
Und dann sitzt er dann immer
und meint so, hm,
das ist vielleicht gar nicht so eine gute Idee in eurem Fall.
Und das
macht ihn halt nicht unbedingt beliebt, aber er versucht das dann irgendwie so diplomatisch zu verpacken.
Aber ganz oft ist es halt so, dass Leute das dann so probieren,
aber eigentlich sollte man vielleicht andersrum anfangen und eher Monolith nehmen
und dann halt, wenn man dann auf bestimmte Probleme stößt, die man anders nicht mehr lösen kann,
dann Microservice ist dann vielleicht eine Möglichkeit unter Umständen.
Aber damit anzufangen, ohne zu wissen, was man jetzt eigentlich machen möchte,
das ist vielleicht nicht so eine gute Idee.
und das ist eigentlich, also wenn man jetzt halt
vorher schon ein Problem mit der Modularisierung
hatte und dann auch noch
Microservices dazu nimmt, dann hast du halt hinterher
einen Distributed Ball of Mud sozusagen.
Also das Problem
an
Modularisierung
kann sein, dass man verschiedene Stellen hat, an denen man
Dinge pflegen muss?
Ne, Modularisierung ist eigentlich eine gute Sache.
Aber wenn nicht, du hast gerade
ein Beispiel gesagt, du hast gesagt,
das ist gut wenn man das hinkriegt das ist gut Wenn man es nicht hinkriegt ist doof aufzunehmen Also wenn du es nicht schaffst sozusagen Dinge voneinander zu trennen Wobei jetzt auch nicht Trennung beliebig super ist
Natürlich kann man das auch falsch machen, in dem Sinne, dass man das an den falschen Stellen trennt,
in der falschen Granulatität trennt. Das ist natürlich nicht schlecht.
Und wenn man jetzt sozusagen es aber gar nicht schafft, das zu trennen
und sagt, wir machen jetzt aber Microservices, um die Sachen, wo wir es falsch getrennt haben,
nochmal zu zementieren, indem wir es auf andere Rechner packen.
und in andere Repositories und so
und dazwischen halt jetzt
Schnittstellen haben, die wir schlecht ändern können und
die, wo wir Fehlerbehandlung machen müssen
und das ist alles ganz, ganz schrecklich, dann
ist das halt noch viel schlimmer als vorher.
Also wenn du vorher das Problem hattest, du hast es nur in deiner
in deinen Funktionsaufrufen
nicht geschafft, das ordentlich zu trennen
und jetzt hast du es halt irgendwie
diese Funktionsaufrufe verteilt,
aber du hast es
quasi nicht wirklich modularisiert,
sondern du hast ja Abhängigkeiten immer noch,
dann hast du danach
ein viel schwereres Problem als vorher.
Du hast es nur dann eine ganze Zeit
lang nicht mehr gemerkt, weil da warst
du damit beschäftigt, irgendwie Kubernetes
zu konfigurieren, so ein halbes Jahr oder so.
Und dann nach einem halben Jahr fällt dir auf,
das Problem ist eigentlich noch viel schlimmer als vorher.
Und das ist halt dann,
dann bist du in einer doofen Position, weil da
kommst du dann auch nicht mehr so leicht raus.
Und ja, das ist halt
genau, ja, das ist halt
ja, Architektur,
genau, also jedenfalls
Damit beschäftige ich mich halt auch gerade so ein bisschen.
Ich meine, da müsste man mal drüber reden, wenn ich da irgendwie mehr zu weiß.
Ich glaube, da müsste man auch eine eigene Folge zu machen.
Oder auch Microservice versus Modulit.
Wenn ihr das auskennt,
dann sagen wir uns Bescheid.
Hallo, ich heiße Martin.
Genau.
Was ich halt gerade versuche, ist halt mich mit diesem
Was macht man denn eigentlich so
üblicherweise, wenn man jetzt eine
Architektur, wenn man überhaupt so ein bisschen
Architektur haben möchte,
wie macht man das denn?
Und zum Beispiel, was ich, ein schönes
Zitat, was es halt in dem Buch, diesem
Software-Energischer-Patterns
was Python-Buch, das ich da so lese,
zu lese, gibt,
ist halt,
und ja, das fällt mir halt dazu,
dann auch allen,
wenn man sagt, ja, super,
ich kenne das, ganz viele Leute,
ah, super, Microsoft ist voll gut,
oder sonst wie, irgendwie,
ja,
das hatte mal, glaube ich, der Autor von
von Clojure
der Programmiersprache
Rick Hickey
hat das gesagt
und hatte so, ja
es gibt immer unter Ökonomen
den Witz, ja, so Ökonomen kennen
wie den Preis von allem, aber den Wert von nix
und für Softwareentwickler
kann man das halt auch anpassen und sagen, ja
Softwareentwickler, die kennen halt
irgendwie die Vorteile von
oder die Features,
aber sie kennen halt irgendwie
die Trade-offs und die Nachteile von Nix.
Und das ist halt,
das ist so ein bisschen, da ist was Wahres
dran und
zum Beispiel
eben, das ist da,
wir hatten ja letztes Mal diese
Fast-API-Episode oder so.
Also,
das ist so,
ich weiß nicht, würde
man, auch
wenn ich das so, auch bei
bei TalkPython-Termin oder so, wenn ich das höre. Ich höre immer so, ja, das ist alles voll gut und so.
Aber es gibt ja auch Nachteile, die das hat, wenn man das jetzt so macht.
Also wenn man jetzt zum Beispiel sagt, man nimmt jetzt FastAPI, nehmen wir mal ein paar Beispiele,
du nimmst halt FastAPI, SQL-Model und so und
alles funktioniert mehr oder weniger automagisch. Was ist der große
Nachteil an dieser Geschichte?
Erzähl. Tja, da würde ich sagen, eben, da bist du schon
Typischer Softwareentwickler, die meisten würden sagen, ja, das hat doch keinen Nachteil.
Es hat halt schon Nachteile und der Nachteil ist halt,
wenn du halt von SQL-Model erbst, dann kannst du das nie wieder ändern.
Wenn du jetzt auf die Idee kommst, wir machen das, oder du stellst halt fest,
du misst das, du hast viele kleine Sachen, die halt serialisiert werden müssen,
das ist halt zu langsam, das funktioniert irgendwie nicht.
Und das ginge besser, wenn ich das jetzt irgendwie mit einem Unpile machen würde oder keine Ahnung,
dann, das kannst du nicht mehr anpassen.
das ist halt einfach, dann hast du halt mehr oder weniger
verloren. Naja, du könntest ja schon
Export der Datenbank machen und Import von anderer Stelle
man muss dann so kurze Downtime kaufen und so
Conversion
dazwischen schreiten, also irgendwie geht das ja schon
Wenn da eine Business-Logik
da drin hängt
und du hast von SQL-Model geabt
oder von
Pidentic, irgendwie von den Base-Models, da kannst du
nicht mehr viel machen, das ist halt dann
das ist halt das Problem, du hast halt
oder sagen wir mal so, ich will gar nicht
auf Fast-API rumhacken oder so, also ich meine
dieser Ansatz ist ja durchaus verbreitet.
Bei allen Frameworks ist es halt so,
du erbst von irgendwas und dann
hast du halt viel mehr
Fähigkeiten und hast halt in kurzer Zeit
sozusagen viel geschafft, aber du kannst es
halt auch nicht mehr ändern. Wenn du das in Django machst, ist das
das gleiche Problem. Wenn du in Django
irgendwie erbst du ja von
Models.irgendwas.model und
hast da deine Fields und so.
Was ist denn jetzt, wenn das aus irgendwelchen Gründen nicht mehr gut
auf deine Anforderungen passt?
Da musst du halt umziehen.
Aber das geht quasi nicht. Endpunkt pro Endpunkt.
funktioniert nicht gut. Das kannst du praktisch nicht mehr ändern.
Also da würde ich sagen, der große Nachteil,
du kaufst dir eine Menge,
du kriegst halt viel Magie einfach so ganz schnell
und es funktioniert ganz viel.
Der große Nachteil, den du dir einkaufst,
ist, du kannst das nicht mehr ändern.
Du hast dich ganz eng
an dein Framework gekoppelt.
Das ist die engste Kopflung, die es überhaupt gibt von irgendwas zu erben.
Und
jetzt eben
sozusagen diese klassische
Software-Architektur würde halt sagen,
ja, Frameworks sind nicht deine Freunde, sei
vorsichtig, wenn du von irgendwie mehr erbst.
Das ist immer, du koppelst dich da ganz eng.
Also all diese Sachen von Sachen erben,
Sachen importieren, alles
vielleicht nicht so gut, weil das lässt sich hinterher alles
selber machen.
Das musst du ja nicht. Du könntest zum Beispiel stattdessen
eine Software-Architektur machen.
Ist halt die Frage.
Du meinst Kapseln dann?
Du kannst es halt
so machen, dass zum Beispiel dein
Kern, deine Applikation halt
von überhaupt nichts abhängen, von XR und auch nichts importiert.
Aber es braucht einen Händler für Speichern von Daten.
Ja, aber den kannst du reinreichen sozusagen.
Genau, aber das ist dann eine Dependency Injection, habe ich das jetzt richtig?
Ja, genau. Du würdest die Dependencies umdrehen.
Du würdest halt sagen, der Kern meiner Software basiert halt
oder hängt halt ab von anderen Sachen, sondern du würdest sagen, man dreht das halt um
und die anderen Sachen hängen halt von meiner Software ab.
und als
Mittel, um das zu erreichen, könnte man
Dependency Injection zum Beispiel verwenden,
aber das muss man ja auch nicht automatisch, also Dependency
Injection oder
Dependency Injection Frameworks,
da wird das ja quasi
so ein bisschen automatisiert.
Man kann das ja aber auch manuell
machen. Also manuell heißt das
eigentlich, du machst das so, dass du
hast halt dann
quasi Schnittstellen oder irgendwelche abstrakten
Interfaces, von denen du
halt, die du halt sagst, okay, das ist halt
das, was hier, so, da wird zum Beispiel
so eine
Datenbank,
ein Repository, ja, das muss jetzt,
sagt gar nicht, was das für eine Datenbank ist,
sondern wird halt reingereicht, ja, dass halt bestimmte
Methoden hat und dann
bestimmte Schnittstelle hat. Also quasi Abstract Base Class
mit Methoden zu
implementieren, die man dann
verwenden muss als Injection und die man dann,
wo dann klar ist, okay, das muss jetzt
so und so implementiert sein, egal wie du das löst, das ist mir
wurscht, aber Hauptsache, du stellst diese Interfaces für mich
bereit, die benutze ich dann einfach und
Input, Output sind vordefiniert. Und man dependet dann
eben auf diese abstrakte Schnittstelle
und nicht auf eine konkrete Implementation.
Das habe ich tatsächlich auch schon mal gemacht.
Ja, das ist ja schon
so richtig.
Kannst du mich jetzt Architekt nennen?
Ich glaube, das darfst du nicht wieder.
Das ist gar kein Problem. Hast du alles schon gesehen,
welche Leute sich Architekt benennen?
Das ist wohl jetzt auch kein geschützter Begriff.
Ja, Informatiker glaube ich auch nicht.
Ich glaube, du darfst dich nicht
Diplom-Informatiker nennen, aber
im Maticast.
Ja, ist auch wurscht.
Jedenfalls,
wenn du halt auf diese Abstraktionen
dependest und nicht auf irgendwas Konkretes,
dann kannst du halt das,
die konkrete Implementation dieser
Schnittstelle halt austauschen.
Wenn du ein Repository hast, das halt irgendwie SQL Alchemy
war, kannst du sagen, okay, ich nehme jetzt ein Django
Repository stattdessen
und dann merkt deine Applikation gar nicht,
dass das geändert wurde.
Der Nachteil ist halt irgendwie
Django OEM und so, das ist ja schon nett,
und du sparst halt viel Arbeit.
Du musst halt dann nochmal selber bauen, die ganzen Methoden,
die es da halt gibt quasi. Und dann halt quasi,
du musst einer die abstrakte Klasse bauen, die musst du dann
für deine Sache identifizieren.
Wenn du das mit dem Django-ORM nutzen willst, dann musst du quasi den Händler
dafür schreiben für deine abstrakte Klasse, die dann
den Django-ORM benutzt, damit die Methoden,
die du dir bereitstellen willst, auch dann darüber gehen.
Ja, also sagen wir so, du verlierst halt
einen Großteil der Gründe, warum man
jetzt... Der Convenience. Der Convenience,
den verlierst du tatsächlich, das ist halt so.
Dadurch, dass du halt Django
austauschbar machst oder FastAPI
austauschbar machst. Ich habe das
überlegt, zum Spaß könnte man eigentlich
noch einen Flask Entry Point
davor hängen, wenn ich damit
fertig sein sollte und das wäre praktisch
kein Problem, das zu machen. Ich könnte halt
Flask gegen FastAPI austauschen oder umgekehrt
oder Django, das wäre alles kein großes Problem,
aber man hat halt auch die ganzen Vorteile dann nicht mehr.
Das ist halt dein Nachteil.
Aber ja,
ich wollte es einfach mal ausprobieren, deswegen habe ich da so ein bisschen
mit angefangen und
ja,
Ja, aber man sollte sich halt, wenn man jetzt
ihm diesen Weg geht und sagt, ich nehme einfach ein Framework, dann ist alles schnell
Ich wusste, dass man das Software-Architektur nennt und so ein bisschen
Hochtraben überlegt
Ja, abstrakte Infrastructures bauen, damit man so ein bisschen
die Dependency-Insertion auslagern kann und damit man reduziert die Abhängigkeit
in seine eigenen Codes von anderen Dingen
und die einfach austauschen kann. Also dieses Pattern
der Dependency Injection in diesem Fall, mit diesem abstrakten
Ansatz, ist glaube ich eine richtig gute Idee,
wenn man Skalierung möchte und irgendwann...
Ja, es hat halt auch so Vor- und Nachweise. Also es hat halt
den Vorteil, dass du dann eben flexibel diese Sachen
austauschen kannst und so und dann halt nicht
davon abhängst, dass wenn irgendeiner von deinen
Dependencies sich nicht so gut
weiß 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,
also wenn du zum Beispiel eben eine klasse CRUD-Geschichte
hast, die relativ einfach ist,
dann macht das keinen Sinn, da viel Architektur zu machen, weil das ist sowieso egal.
Aber genau, ich mache es jetzt auch nicht, weil es nötig ist, sondern einfach nur, um zu verstehen.
Lass dich auch fanden, ich habe genug Zeit und mache da so schöne Sachen.
Genau, das ist einfach nur Spaß.
Das ist auch immer ein Selbstzweck.
Vielleicht noch erzählen wollte, da ich immer so viele Webentwicklungen mache,
fehlt mir halt dieser ganze
Machine Learning Teil so ein bisschen. Ich bin da
momentan auch nicht so richtig auf dem Laufenden.
Wenn ich letztens wieder einen Podcast gehört habe, so krass,
was da alles so passiert.
Da wusste ich ja gar nichts von.
Ich kann auch
sagen, dass ich jetzt ein bisschen Unsinn erzähle, weil ich da nicht mehr so richtig
drinstecke, aber vielleicht ist es ja interessant. Also mich hat es
auf jeden Fall überrascht.
Einmal gibt es halt jetzt die Bestrebung,
das kennst du ja wahrscheinlich auch, es gibt so große
Modelle, die trainiert werden auf irgendwie
self-supervised trainiert werden auf
quasi im Internet zum Beispiel.
Modelle gibt es da, diese GPT-3.
Und die machen ja alles
irgendwie so ein bisschen besser, wenn man jetzt irgendwie die verwendet.
Und dann sozusagen das eigene Problem
darauf feintunt 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.
oder 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 feintunst
es nicht mit ein paar hunderttausend, was auch immer
Beispielen, sondern
du sagst zum Beispiel GPT-3 einfach
so, irgendwie dein Job ist jetzt
Übersätze von Englisch nach Deutsch.
Und du tust das einfach so, ohne dass du ihm
irgendwelche Trainingsbeispiele gezeigt hast.
Oder du sagst ihm, dein Job ist jetzt
Übersätze 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.
Und für viele andere Tasks
geht das auch. Ich glaube, es gibt dann auch wieder die Frage,
wie man das nennt, dann Instruction-Based
Learning oder Zero-Shot Learning.
Die KI-Conconscious so ungefähr, ja.
Ja, das weiß ich nicht.
Aber es ist
auf jeden Fall beeindruckend, was damit geht.
Und es gab dann halt so, tatsächlich,
das wusste ich überhaupt nicht, dass das existiert.
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.
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 solche, diese großen Modelle wohl
dazu bewegen, Dinge zu tun,
die ganz erschauend nicht sind.
Genau, wie beim Copilot ist das auch so ein bisschen so.
Copilot ist auch so, ja.
Gute Beispiele gibt es, also gute Methoden und so, gute Namen,
gute Argumente, gute Docs, lernt ja sehr gut
raus. Also wenn man das in einem Projekt mal so konstant hat,
da ist es echt gut wert.
Ja, genau.
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 so ein bisschen, als wäre dann schon alles
passiert.
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
selbst
supervised, ist halt auch nicht so ganz richtig,
weil es ist nicht immer selbst supervised.
Wir müssen dazu auch noch eine Machine Learning-Folge machen, glaube ich, das wird sich
sehr interessant. Ja, aber da brauchen wir auch jemanden,
der sich damit wirklich auskennt, nicht so der
Papauskast-Wörter 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 macht das ein bisschen
klarer, weil wir wissen auch nicht so genau, wie das
jetzt, es wird halt auch,
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 auch mal sehr
interessante Sachen gehen
und vielleicht ist es
eben auch nicht nur selbst super weiß, vielleicht kann man auch
irgendwie bei ImageNet oder so, hat man ja das rein
super weiß 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 das ist so ein bisschen unklar, aber
sind irgendwie die Foundation für
alle möglichen anderen Dinge, die man damit macht.
Also lass uns die doch Foundation Models nennen und
sozusagen da irgendwie die ganzen Themen,
die jetzt da dran hängen, halt irgendwie mit
Abflussstü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
tätig sind, also wenn man sich den Code anguckt,
so
ist halt oft theoretisch
sehr avanciert
und irgendwie Leute machen sich da viele Gedanken
und so, sind sehr kreativ und
machen irgendwie
Klasse Mathematik, aber irgendwie jetzt so den Code, den sie schreiben, ist manchmal schon so ein bisschen unangenehm.
Also da geht auf jeden Fall noch was.
Das hast du 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 auf irgendwas beschränken.
Aber da ist auf jeden Fall noch nicht so das Ende der Fahnenstange erreicht.
Und was ich jetzt interessant fand, ist, dass es jetzt Leute gibt, die aus dem Softwareentwicklungsbereich kommen,
die sich das angucken und sagen, da kann man ja noch was machen.
Und das hat jetzt wieder Einfluss auf die Forschung.
zum Beispiel eben aus der
Kettel-Ecke kommende einige,
also Competitive Machine Learning
oder halt auch aus der Industrie,
es gibt da zum Beispiel einen, Ross Whiteman,
der
sich diese ganzen
Standard-Image-Modelle mal nochmal angeguckt hat
und
der dann im Wesentlichen rausgefunden hat,
naja,
also das, was ihr sagt,
also es gibt der State-of-the-Art
sozusagen für den Score
auf bestimmten Problemen, jetzt nehmen wir ImageNet oder so,
der wurde ja ermittelt
für bestimmte Modelle vor ein paar Jahren
so inzwischen hat es aber nicht nur
Fortschritte bei den Modellen gegeben
also wie ist die Architektur der Modelle oder so
auch bei den Kameras
das spielt alles nicht so eine große Rolle
weil man kann eh nur kleine Bilder nehmen
weil die Datenmengen halt sonst
schwierig für die Modelle wären
aber wo sich was getan hat
ist zum Beispiel sowas wie
wie trainiert man die Dinger eigentlich
und
Python.
nicht mehr dabei und andersrum.
Ich bin gespannt.
Wir machen auf jeden Fall noch eine Episode
dazu, das ist versprochen. Ihr seht, Jochen ist ja auch
sehr bewiesen und
ich finde das auch super interessant.
Vielleicht nochmal kurz zum Abschluss zu bringen.
Es ist auf jeden Fall so, dass
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 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
und so weiter.
Ja, ich weiß nicht, jetzt haben wir das Problem. Aber jetzt bist du dran, jetzt muss ich erst mal meinen Pick wieder nachgucken, den du mir ja versaut hast. Was würdest du denn picken?
Ich muss was picken, in dieser Folge schon wieder.
Ich weiß nicht, wo könntest du?
Ja, ich picke Critical Role. Das ist eine wunderschöne Serie, die auf Prime läuft. Falls jemand sich für D&D interessiert, es gibt einen Vodcast von Matthew 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 Machine.
Es war eigentlich
gar nicht geplant als Fernsehserie natürlich,
aber irgendwer sagt, 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 irgendwer gesagt,
ach, ja, kein Comic. Ja, vielleicht doch.
Ja, da brauchen wir doch irgendwie Geld für. Ja, dann lass doch einen Kickstarter
machen, meint dann irgendwer. Dann sagt er, ach,
hat irgendwer einen Kickstarter gemacht. 48 Stunden
später irgendwie 11 Millionen Dollar oder so eingenommen.
und dann haben die gesagt, 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&D, eine Abenteurergruppe,
die es live gab quasi, gibt es auf YouTube, kann man
die echten Abenteuer nachhören, also eine
Folge ist, glaube ich, so dreieinhalb, vier Stunden oder so was
und die haben, glaube ich, 150 Sessions abgehalten
für diese Kampagne. Das ist also ein bisschen
verkürzt dargestellt, aber
ja.
wo wir eben bei
Jackshaving waren
was man alles verbessern und optimieren kann
und wie tief das bei euch jeweils ist
aber nur ein kleines bisschen was Privates
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 Show Notes nach
es gibt Rich
also es gibt ja Typer, das macht auch schon eine Menge
so Commandline-Geschichten
es basiert aber auch auf Click
und es gibt jetzt 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 dürft diese Episode nicht ganz so
verstören wie uns und
schreibt beim nächsten Mal wieder ein.
Und ja, wie gesagt, schreibt uns gerne alles, was
euch beschäftigt an hallo-at-python-podcast.de
Bis zum nächsten Mal.
und bis dahin.
Tschüss.