Transkript: GUI-Applikationen am Beispiel von MiaPlan

Ja, hallo liebe Hörerinnen und Hörer, willkommen beim Python Podcast.

Heute Jubiläums-Episode 50.

Herzlichen Glückwunsch, Jochen.

Ja, herzlichen Glückwunsch zurück.

50 sind wir schon.

Wow.

Ja, ganz gut, oder?

Wir sprechen heute über Qt und andere grafische Anwendungen in Python und über Mia Plan, das dahin gebaut ist.

Und haben den Martin zu Gast.

Hi Martin.

Hallo, hierallo.

Ja.

Wollen wir ein bisschen News machen?

Ja, diesmal vielleicht schon, hatten wir das letztes Mal ja nicht.

Genau, und dann mache ich das hier gerade mal auf, was wir da so.

Ja, also es gibt halt so ein paar langweilige Software-Geschichten, wo es vielleicht nicht schlecht wäre zu wissen, dass das passiert.

Es gibt, äh, es gab jetzt, das ist aber auch schon was länger her, ich habe jetzt ja dummerweise die News von zwei Episoden und dazwischen ist auch mal was ausgefallen.

Kann sein, dass es jetzt doch ein bisschen veraltet ist.

Also zum Beispiel, was ich hier drauf habe, ist, dass die Einzelversion von MyPy rausgekommen ist.

Was vielleicht ganz interessant ist.

Also ist auch nochmal das.

Was rausgekommen gewesen war, wolltest du halt sagen.

Ja, ist schon länger her.

Und das Einzige, was mir jetzt noch so in Erinnerung ist, ist halt deutlich schneller geworden damit auch.

Ja, ansonsten SQL Alchemy 2 ist raus.

Da war auch das, was man quasi an coolen Dingen verwenden konnte, war schon in 1.4 irgendwie drin.

Und der 2-0er-Schritt ist, glaube ich, nur, dass jetzt Sachen deprecated sind, die halt vorher noch gingen und jetzt gehen sie halt nicht mehr.

Deswegen halt der Major-Versionssprung.

Aber eigentlich auch ganz interessant, weil so gerade so Async-Geschichten ist halt das ist auch da noch relativ neu.

Also dass man da halt so mit, na, wie heißt das?

PG Async PG.

Async PG, genau.

Das auf Postgres zum Beispiel zugreifen kann.

Und das halt alles so ordentlich funktioniert.

Ja, da hatte ich auch schon viel Spaß mit.

Dann Wagtail hat sich eine ganze Menge getan.

Da habe ich hier noch die Release-Notes drin von Wagtail 4.2.

Ui.

Und jetzt ist aber schon 5-0 gestern erschienen.

Das ist tatsächlich ja, also.

Wie viele Baking-Chases gab es diesmal?

Doch, gab es ein paar und ich hatte auch da so ein bisschen Probleme mit.

Also das war nicht so, das war schon ein etwas holprigeres Update, weil, also dazu, die Software, mit der wir hier den Podcast irgendwie publishen, basiert halt auch auf Wagtail.

Django Cars.

Genau.

Und auf Django natürlich.

Und ja, deswegen kriege ich das immer mit.

Wenn es da irgendwas bricht, dann bricht es halt ja auch.

Der Grund, warum ich es nicht mehr mitkriege, ich habe es aus diesem Grund rausgeschmissen.

Ja.

Aber also, ja gut, sie machen da was dran.

Sie machen das jetzt auch über Major-Versionen.

Also man kriegt zumindest so ein bisschen irgendwie einen Eindruck davon, dass irgendwas kaputt gehen könnte, wenn sie dann die Major-Version erhöhen und sie koppeln sich jetzt auch quasi an den Django-Release-Prozess dran.

Und das war jetzt auch nur ein Monat nach dem Release von Django 4.2.

Also Wagtail 5 ist die erste Wagtail-Version, die offiziell Django 4.2 unterstützt.

Und das ist, früher war das immer noch ein bisschen länger.

Und jetzt inzwischen ist es halt so einen Monat später oder so.

Und das ist jetzt, ja gut, ist nicht super aktuell, aber.

Ein Monat ist ein Monat.

Ja, ist schon ganz okay.

Die müssen halt auch relativ viel fixen und ändern und so.

Daher ist es schon verständlich, dass es nicht immer sofort geht.

Aber Jochen, du bist doch eigentlich immer dagegen, dass man sich so dicke Klötze ans Bein bindet.

Ja, ich hätte das auch am liebsten vermieden, wenn das irgendwie möglich gewesen wäre, aber ich möchte, also ich hätte jetzt auch ein eigenes CMS schreiben können, ja.

Das wäre auch gegangen.

Aber das wollen wir nicht.

Wir hatten letztens jemanden getroffen, der hat ein eigenes CMS in PHP geschrieben, kann das sein?

Ja, ne, oder hat er mitgebracht, meinst du, wir waren auf dem Meetup.

Auf dem UJS Meetup, auf UJS Meetup Cologne.

Das war ganz interessant, ja.

Der hat, der hat ein Statamic mitentwickelt, beziehungsweise einer der Leute, die da halt bezahlt werden für das sie dann entwickeln.

Das ist tatsächlich so ähnlich wie Wagtail bloß halt für PHP und Laravelle.

Und ja, nee, das ist also CMS ist schon eine große Geschichte.

Wagtail ist auch relativ groß, viel Code drin und das weiß ich nicht, ob man das wirklich selber machen möchte.

Es gibt da ein schönes Projekt von, jetzt habe ich den Namen vergessen, auch sehr bekannt eigentlich in der Kerstin, in der in der Djungo-Community, genau, der hat FeinCMS geschrieben.

Und das gefällt mir, also wenn man sich den Source anguckt, das gefällt mir tatsächlich auch ein bisschen besser als Wagtail, aber es kann halt nicht so viel.

Und ja, an der Stelle ist halt Wagtail kann halt schon sehr, sehr viel.

Also das ist halt irgendwie, also damit kann man so ziemlich alles machen, was man irgendwie gerne machen möchte.

Fein CMS, also tatsächlich ein deutsches Fein und kein englisches Fein.

Ja, ich glaube, der kommt aus der Schweiz oder so.

Und ja, also ich meine, sowas hätte ich natürlich auch schreiben können oder das nehmen können, aber dann hätte ich auch viel schreiben müssen, weil viele Sachen, die ich gerne hätte, sind da halt auch nicht drin.

Alter sein, Copyright 2009.

Der macht das schon lange, ja.

Ja, ja.

Und ja, deswegen nehme ich halt Wegteil, obwohl ich auch manchmal denke, so, oh, so ja, es knircht halt ab und zu.

Das letzte Release war die Kompatibilität mit Django 1.10.

Nee, das dann bist du wahrscheinlich auf einer falschen Seite.

Der ist schon noch, da ist auch in letzter Zeit nochmal was dazugekommen, meine ich, ja.

Es gibt da möglicherweise auch unter, vielleicht ist dann auch Fein CMS 3 oder so.

Das hat auch mehrere Major-Versionen inzwischen.

Ja, also Wacked, also für CMS, also ich früher immer gedacht hast, ja gut, was ist das schon groß, aber es ist halt, da hängt schon eine ganze Menge Zeugs dran.

Und was jetzt zum Beispiel mir Probleme gemacht hat bei dem Update, ist halt, dass sie intern irgendwie einen, weil ich habe halt eine Extension, also ein Ding über Ort, was das halt so ein bisschen erweitert, weil ich habe halt viele Bilder für andere Zwecke.

Jetzt bei dem Podcast kommen nicht so viele Bilder vor, aber waren noch andere Interesse Sachen.

Man möchte gerne Bilder in der absolut maximal bestmöglichen Qualität.

Ich möchte, dass sie nicht total unscharf sind.

So oder so sehen.

Ja, aber ich sehe das schon.

Ich denke mir immer, immer wenn ich auf so Seiten, also gerade auch Wegtail-Seiten, es gibt ja viele andere, die auch Wactail verwenden, so unter anderem NASA, Google, irgendwie der National Health Service in den UK und so.

Es gibt schon viele große Nummer, wenn ich da drauf gucke, ich denke mir so, äh, die Bilder sind doch unscharf.

Tausend Leute haben auch dieses Problem.

Ja, also ich weiß nicht.

Also ich finde super, ist das cool.

Mir ist es tatsächlich auch aufgefallen, wenn ich mal so ein paar Sachen von dir angeguckt habe, dass das sehr viel schöner ist.

Wahrscheinlich hat man sich einfach nur daran gewohnt, dass die Sachen gar nicht so cool aussehen.

Dass das gar nicht so schön sein kann, weiß man gar nicht

so genau.

Ja, also sagen wir so, ich meine, selbst WordPress macht das besser, ja.

Also das hat da zwar auch nur so drei oder fünf statische Größen für Bilder drin.

Also das Problem ist grundsätzlich, dass wenn du, du hast halt zwei unterschiedliche Arten von Pixel, du hast halt sozusagen die Pixel für deine, wie groß dein, wie breit quasi dein Bildschirm ist oder so und dann kannst du auch in Pixeln rechnen.

Aber das, was angezeigt ist, was wird, ist halt was anderes.

Weil es halt mittlerweile halt Devices gibt, Telefone, irgendwie Bildschirme, 4K-Bildschirme oder noch mehr, die halt dann mehrere physikalische Pixel für einen virtuellen Pixel quasi benutzen.

Und wenn du halt nicht sozusagen dann die Bildgrößen entsprechend mitlieferst, sondern sagst, mein Bild ist halt genauso breit wie so, so viele virtuelle Pixel, dann hast du halt ein implizites Upscaling von Faktor 4 oder so drin und dann wird es halt unscharf.

Und ja, das ist halt irgendwie, da gibt es noch, sie arbeiten da auch dran.

Also so ist es nicht.

Da gibt es jetzt inzwischen auch eine sehr vielversprechende, da gibt es so eine Roadmap, wo drin steht, was sie da machen wollen und sie wollen das mit Picture-Element machen und irgendwie so modern oder so.

Ihre Hauptmotivation dabei ist aber eher irgendwie Bandbreite sparen, weil man dann halt so modernere Formate wie WP oder solche Sachen verwenden kann.

Aber damit kriegt man das auch hin, dass man dann halt scharfe Bilder hat.

Mein Ding ist aber eher, ich will scharfe Bilder haben und JPEG reicht mir eigentlich.

Und deshalb habe ich da so ein Ding geschrieben und da haben sie jetzt irgendwas umbenannt.

Irgendwie ein Attribut auf dem Image-Node heißt jetzt irgendwie anders, weil ich muss jetzt halt, also meine Erweiterung für Wagtail, die Render, die erzeugt halt dann Bilder in unterschiedlichen Größen und macht da so ein Sorcet-Attribut für.

Und dann, äh, genau, und da greife ich halt auf irgendwie so die Filter von dem Ding irgendwie zu, weil du kannst ja auch noch andere Sachen reinschreiben, wie JPEG-Qualität und weiß der Teufel und die Breite.

Und das muss ich ja irgendwie auslesen und das hat sich irgendwie umgenannt.

Vorher war es ein String, der irgendwie so durch so Pipes getrennt war und den habe ich dann gesplittet und jetzt ist es halt irgendwie die Liste schon gesplittet.

Und jetzt muss ich halt eine Fallunterscheidung machen zwischen, also wenn es eine neue Version ist so.

Es war nicht mal irgendwie so ein.

Es war eigentlich ein, ja, und solche Sachen machen halt schon eine Arbeit, ja.

Da habe ich so ein bisschen was jetzt machen müssen.

Aber insgesamt ging es eigentlich.

So schlimm war es nicht.

Und jetzt laufen halt auch, läuft alles irgendwie auf Django 4.2 und Wagtail 5.

Und das ist eigentlich schon nett.

Also Wegtail, wenn man sich das vor einiger Zeit angeguckt hat und nicht zufrieden war, kann man das eigentlich nochmal machen, weil.

Also einige Zeit heißt bei mir nach

drei Jahre her, würde ich sagen.

Zwei Jahre reicht es auf jeden Fall.

Also inzwischen hat sich da sehr viel getan.

Also die Changelogs sind halt auch mal sehr lang.

Also würde ich sagen, was ist an dem modernen Wackteil eigentlich cooler?

Was sie verbessert haben, ist, also es gibt ja schon seit einiger Zeit so ein Stream-Field.

Das ist auch, das machen alle CMS-S irgendwie gleich, ja.

Video, Audio und der Genäg.

Dass du halt nicht, ja, du hast halt einen JSON-Field irgendwie in der Datenbank oder so und dann hast du halt so Blöcke drin, wo halt in dem Block steht halt sozusagen drin, was das jetzt ist.

Ist das jetzt ein Text oder ist das jetzt ein Bild oder ist jetzt und dann kannst du die sozusagen, hast du ja eigene Widgets dafür bauen, um solche Sachen einzutragen.

Und ja, Obercell macht das halt auch, aber das war, wenn das sehr groß wurde, früher dann halt schon auch eher langsam und so und ein bisschen komisch, weil das halt alles, weil die HTML-Formulare so unfassbar riesig groß geworden sind, wenn du halt viele Dinger drin hattest.

Und du musst es ja, du musst ja dann Formulare für jeden Eintrag quasi generieren.

Und das ist jetzt, jetzt ist das Editieren von Wagtail ist jetzt auch eine React-App, kann man auch sagen, so Igit.

Aber, also das ist halt einer der Vorteile, ist halt, wenn man jetzt riesige Seiten hat mit ganz, ganz vielen Formularen oder so, dann ist das halt nicht mehr langsam beim Rendern oder wenn man irgendwas ändert, dann muss nicht alles neu gerendert werden, weil es halt nicht mehr klassisch ist, sondern dann passiert das alles im Client nur noch und das geht jetzt schneller.

Also überhaupt das ganze Ding ist deutlich schneller geworden.

Also ich meine, so sehr React irgendwie doof ist für so die Sachen, für die es oft verwendet wird, für sowas wie eine komplizierte Content-Editiergeschichte, wo halt irre viele Formulare sind und es Interaktionen dazwischen gibt und dafür ist es jetzt vielleicht auch nicht so schlecht, das ist eigentlich ganz schlecht.

Sieht das denn gut aus und kann man das denn theme?

Theme kann sein, das weiß ich dir, kann man.

Man kann auf jeden Fall Dinge ändern.

Also ohne dass man jetzt halt massiv wieder rein.

Eines der neuen Features bei 5, Vektor 5, es gibt jetzt eine Dark-Theme.

Oh ja.

Wer braucht das nicht?

Genau, ist mir direkt aufgefallen, weil ich das dann auch direkt hatte, weil ich hier auf dem Dark-Mode bin.

Ja, es sind einfach für die Augen viel angenehmer.

Naja, also ich finde, es sieht ganz okay aus.

Also so wirklich hübsch ist es nicht, aber ich meine, das ist ja nur das Editierding.

Es ist ja nicht so, also wie es dann hinterher aussieht, was auf der Webseite zu sehen ist.

Das kannst du ja machen, wie du willst.

Das hat ja nichts mit Ractiles zu tun.

Ja, insofern.

Jetzt hat mir fast eine schöne Übergleitung aus dem Thema, aber ich glaube, wir sind noch nicht ganz fertig.

Nee, da kommt noch, o je, genau, nächstes wäre halt Django 4.2, ja, auch nächste LTS-Tech.

42?

Ja.

War auch jetzt, da war auch wenig drin, was irgendwie kaputt gegangen ist.

Die große Neuerung da ist halt, dass man jetzt auch Async mit der Datenbank sprechen kann.

Und zum Beispiel Psycho PG3 wird jetzt unterstützt und dann, also sozusagen, man hat jetzt die Voraussetzung dafür, dass man komplett Async von vorne bis hinten, sozusagen von Frontend, von View bis zur Datenbank, kann man halt jetzt durchgängig Async-Dinge machen.

Und man könnte jetzt so Sachen bauen wie man verwendet diesen Listen-Notify-Mechanismus von Postgres, um halt wirklich so richtig reaktiv Dinge zu machen.

Also ging auch vorher schon, aber da war es immer so ein bisschen, hm, jetzt geht es halt, also da muss man Jungle Channels verwenden und weiß nicht.

Aber jetzt ging es halt richtig sauber eigentlich.

Also da gibt es noch keine wirkliche Unterstützung für.

Das müsste man dann alles selber schreiben, aber es geht jetzt theoretisch zumindest schon mal.

Und das ist eigentlich schon schön.

Auch der ORM könnte jetzt dann halt irgendwie Async werden, der hat ja auch schon Async-Interfaces.

Aber die sind ja, also sagen wir mal die kann man auch schon verwenden und kriegt dann halt irgendwie den Gewinn, dass es wirklich Async ist, irgendwann, wenn das dann halt mal im Prinzip ist.

Momentan ist es dann halt nicht Async wirklich, sondern es ist halt dann irgendwie, es wird über ein Threadpool und in Sync gemacht.

Aber ja, so das wird noch ein bisschen dauern, bis die ORM-Geschichten halt auch wirklich Async sind.

Aber ja, geht auf jeden Fall in die Richtung und irgendwann dann wird da auch alles auf Async dann quasi umgestellt sein.

Und man kann es dann verwenden, wenn man möchte.

Muss man ja nicht.

Man kann auch einfach Sync verwenden.

Wenn man nicht so viele Quaries hat und wenn es, wenn man es, es ist ja async, ist auch mal ein bisschen schneller als Async, weil man da halt schon noch so ein bisschen Abstraktionsschichten mehr dazwischen hat, dann.

Aber es gibt halt ein Fälle, in denen es wäre es total praktisch, das zu haben.

Und dafür ist es natürlich gut.

Kannst du nochmal einen Anwendungsfall dafür nennen?

Ne, wenn du zum Beispiel viele Queries machst und du willst halt nicht, dass sich die Latenzen und deine Datenbank steht jetzt zum Beispiel woanders, sagen wir mal so.

Das wäre jetzt nochmal, also nehme an, deine Datenbank steht irgendwie in Amerika und du hast hier deinen Applikationsserver oder wie auch immer, das Ding, was halt jedenfalls das HTML rendert, ist halt irgendwo so.

Und jetzt hast du halt große Latenz zwischen Datenbank und Frontend, dann momentan ist es halt so, leider addieren sich die Latenzen auf.

Und wenn du halt 100 Queries machst, um eine Seite anzuzeigen, dann hast du 100 Mal die Latenz dazwischen und das ist halt dann schon ätzend.

Also wenn das halt nur ein paar Millisekunden sind, dann sind es halt insgesamt ein paar hundert Millisekunden vielleicht.

Das ist nicht so tragisch, aber wenn du jetzt 50 Millisekunden Latenz dazwischen hast, dann bist du halt schon bei 5 Sekunden oder sowas.

Und dann ist es halt doof.

Und genau, und wenn du das ISIN machen würdest und könntest die Request, die Datenbankrequest gleichzeitig an die Datenbank schicken, dann wäre die Gesamtlatenz halt nur die Latenz der langsamsten Query und nicht irgendwie, die würden sich nicht alle aufhaddieren.

Also in solchen Fällen wäre es halt irgendwie durchaus so praktisch.

Ja, also genau, Django Fear 2.

Ich weiß jetzt gar nicht genau, was sonst noch da an wirklich, da waren auch noch jede Menge coole Sachen dabei.

Ah, das habe ich jetzt gar nicht mehr so in Erinnerung.

Es ist auch schon wieder ein Monat her, dass das veröffentlicht wurde.

Und bei Formularen hat es sich auch noch eine Menge getan.

Also ja.

Und es sind einige Sachen noch deprecated worden.

Ja, also, keine Ahnung, kann man sich mal angucken.

Der kam bestimmt auch dann die Roadmap für Django 5, oder?

Ja, bestimmt irgendwie.

Keine Ahnung.

Es gibt auf jeden Fall schon Leute, die sich darüber Gedanken machen.

Ich habe auch schon so ein bisschen gehört, was bei Django, also bei Django 5, die nächste Geschichte, die jetzt angegangen wird.

Es ist halt jetzt so, ich habe das jetzt nicht irgendwo gelesen, offiziell, sondern ich habe das jetzt so, was ich so mitkriege.

Und ich dachte ab und zu irgendwie so mitlese, was da so passiert.

Sie wollen das Request-Objekt, das halt uralt ist und das sehr schwer zu ändern ist, so ein bisschen anpassen.

Also da gibt es ja immer noch momentan so Request.get und Request.post und Post und Get sind groß geschrieben.

Und das ist quasi genauso, wie das damals halt so in CGI oder PHP war, wo man das dann halt sozusagen diese Inspiration für diese Geschichten her hatte.

Aber das ist natürlich jetzt heutzutage eigentlich blöd.

Und man hat es aber nie geändert in den letzten 15 Jahren, weil klar ist, dass wenn man das ändert, dann brechen halt überall Deployments, in denen halt irgendwie, keine Ahnung, Leute darauf halt zugreifen und deswegen kann man das nicht so einfach jetzt irgendwie umbenennen.

Ja, aber da soll jetzt was passieren.

Und zwar hat man jetzt einen Grund, um diese großen Änderungen anzugehen.

Und zwar soll halt so ein bisschen Fähigkeit zu JSON generieren und so.

Also ich glaube, die harten Sachen, die man dafür braucht, also der Umgang mit unterschiedlichen, ach, ich weiß es gar nicht mehr gesagt.

Also jedenfalls die Basisarbeit dafür ist schon drin.

Diese ganzen, ja, da geht es irgendwie um Header und weißer Teufel irgendwie Support.

Aber was man eigentlich gerne hätte, ist ja, dass man JSON rausrennen kann und das halt auch ordentlich funktioniert.

Also sozusagen, eigentlich wird jetzt quasi die Basis dafür gelegt, dass sowas wie Django Rest Framework eigentlich in Django Core mit reinwandert.

Oder man das halt sowas wie Django Rest Framework eigentlich gar nicht mehr braucht.

Weil die schwierigen Teile in Django Rest Framework, die sind jetzt eigentlich schon in Django Core drin.

Und jetzt geht es halt auch darum, das alles so ein bisschen aufzuhübschen, das Request-Objekt zu modernisieren, dass man halt jetzt sehr vielleicht da JSON da auch rausrennen kann oder irgendwas anderes halt XML.

Gut, mittlerweile benutzen alle nur noch JSON.

Ja, das ist auf jeden Fall das, was man.

Und eine von den Sachen in Django 5 ist Formulare.

Django 5 ist auch Formulare?

Ja, ein bisschen besser davon.

Also Formulare sind auch jetzt schon, da wird auch schon viel dran gemacht.

Ja, ich meine, also der Anwendungsfall an der Stelle ist halt einfach, dass man lieber, also das war früher etwas schwierig.

Man möchte halt Teile von Formularen und so rendern können, besser.

Also gerade so interaktiv möchte man gern das Verhalten so haben, wie man das in der SPA halt auch hat, nur halt mit ordentlicher Server-Seite, Validierung von irgendwelchen Eingabedaten und so.

Und das geht natürlich auch.

Also habe ich auch schon häufiger gemacht, dass man dann halt, sobald sich irgendwie ein Feld von einem Formular ändert, dass man dann halt das an den Server schickt und dann kriegt man halt sozusagen nur das gerenderte Feld zurück und ersetzt das dann.

Und dann, wenn da eine Fehlermeldung drin steht, dann steht die halt auch da drin und so, das geht alles.

Aber irgendwie zum Beispiel mit Crispy Forms irgendwie einzelne Felder rendern, ist halt, ist es möglich.

Es ist halt irgendwie nicht, es macht keinen Spaß.

Und das zu testen macht auch nicht so richtig Spaß und das ist alles so ein bisschen.

Und ja, da wird auch viel daran gearbeitet, damit das halt einfacher wird und besser geht alles.

Ja.

Ja, genau, Django 4.2, ja.

Ich hab die Twitter-Appis kaputt.

Ja, äh, das ist auch schon lange her.

Bei Twitter ist noch alles möglich kaputt gegangen.

Ja, es ist.

Du machst ja immer gerne so einen Pann, deswegen dachte ich, es ist absolut.

Ich glaube, das ist echt total veraltet, was da drin steht.

Also das ist irgendwie von vor zwei Monaten oder so, dass das halt, ähm, dass jetzt die APIs zugemacht haben.

Ja, und das halt für viele Leute war das halt echt nochmal so ein Grund, dann auch zu Masterun zu wechseln, weil für Mastodon gibt es jetzt noch irgendwie ordentliche Apps und Twitch wird halt nicht mehr.

Gibt's nur die, äh, die, die, äh, die Standard-App und die ist halt Mist.

Ja.

Genau.

Ah, was auch noch ganz interessant ist vielleicht, ist, es gibt das Paydentic.

Paydentic hat irgendwie Venture Capital eingesammelt.

Oh.

Ja, ja.

Fünf Millionen von Sequoia oder so.

Okay.

Was ich jetzt weiß ich nicht, ob man sich darüber freuen soll oder ob man besorgt sein soll.

Gut oder schlecht.

Das kann beides sein, das ist so klar.

Ich weiß nicht genauso, wie sie sich vorgestellt haben, dass sie das Investment wieder reinholen, aber weil das ist natürlich das Problem.

Wenn man jetzt irgendwie ganz viel Infrastruktur, also Bydentik als Infrastruktur verwendet und darauf aufbaut, dann ist es so, okay, haben die jetzt ein großes Incentives, mich irgendwie dafür bezahlen zu lassen.

Das will man vielleicht nicht unbedingt, aber ja, auf der anderen Seite, was natürlich vielleicht schon schön wäre, ist, wenn da halt so ein bisschen mehr, also ich glaube, der hat dann noch, also hier, wie heißt er noch?

Nee, das ist der von FastAPI.

Aber der ist Samuel Colvin, glaube ich, heißt der, von Payentic.

Macht Jan schon natürlich auch mit Paydantic?

Ja, kann sein, weiß ich nicht so genau.

Aber der hat jetzt dann auch irgendwie Leute angeheuert und jetzt gibt es da noch ein bisschen mehr Druck irgendwie beim Entwickeln an der Stelle.

Und das ist natürlich vielleicht schon nicht so schlecht, weil, also Piedentic ist ja eigentlich schon eine sehr coole Idee.

Ich fände da das auch mal gerne, wenn man mal halt irgendwie so wirklich validieren will, dass die Daten, die man irgendwo reinbekommt, halt so richtig

tatsächlich dementsprechend,

was man erwartet.

Ja, hat eine so schöne Syntax.

Man schreibt eigentlich nur die Type-Annotations hin und dann, genau, hat man hinterher validierte Daten.

Das ist ja alles.

Ja, genau.

Aber was halt so ein bisschen problematisch ist, ist halt, es ist sehr langsam im Vergleich zu Standard-Python-Objekte irgendwie einfach nur erstellen.

Da kannst du ja Python Decor nehmen, damit das dann auch in Rust läuft.

Ja, genau.

Und wenn das dann in Rust, ist es natürlich, aber es ist natürlich auch klar, dass es mit mehr Arbeit, das in Rust zu schreiben und so.

Ja, also mal gucken.

Aber es ist auf jeden Fall eine interessante Entwicklung und gut, ja.

Wie es ausgeht, wissen wir nicht.

Dann haben wir noch, was haben wir noch?

Node.js 20, naja ich weiß nicht, ob es da irgendwas interessant ist.

Nö, eigentlich nicht.

Ja, Pythonista ist eine neue Version veröffentlicht worden.

Das freut mich ja total, aber ich glaube, vielen Leuten wird das nichts sagen, aber es gibt für iOS eine App namens Pythonista und da kann man tatsächlich Python-Code ausführen.

Also man kriegt dann halt so eine richtige interaktive Shell und da ist auch NumPy mit drin und der ganze Kram.

Aber auf dem Telefon.

Achso, ey.

Und man kann sogar dann Python-Code.

Ja, ja, man kann da auch Programme dann ausführen und so, man kann die auch, kann auch so sich, das habe ich schon mal gemacht, dann, dass man im Share-Sheet sagen kann, ich share das jetzt mit irgendwie einem Python-Skript und dann kriegt das Python-Skript das und kann damit irgendwas machen.

Also man kann da tatsächlich irgendwie Python-Code auf Telefonen und iPads und so ausführen.

Und das ist jetzt halt in einer Version erschienen, dass Python 3.10 unterstützt wird und ja, das ist schon sehr nett.

Also das ist wirklich, wie das mit dieser Policy, App Store-Policy vereinbar ist, dass eigentlich nur Objective-C, Swift und irgendwie C und C<unk> irgendwie ausgeführt werden können sollen.

Ist mir nicht so ganz klar.

Eigentlich war es wahrscheinlich zu unbekannt, dass da jemand wirklich mal drauf geguckt hätte.

Jetzt rausgekickelt.

Naja, aber es ist wirklich toll.

Also das ist auch mit sehr viel Liebe.

Handgedengelt.

Ja, sehr schön.

Ja.

Ich finde, wir können ja langsam mal übergehen, oder?

Wir könnten langsam mal übergehen, ne?

Interessanten Dingen.

Genau, machen wir doch einfach mal so allmählich das Thema.

Ja, ansonsten habe ich ja auch noch so ein Metagram und so.

Ja, also wir wollten heute so ein bisschen über grafische Interfaces reden, die jetzt in Python.

Haben wir noch nie gemacht, ja.

Genau, und was man da machen kann.

Also ich höre ja immer oder ich weiß das aus eigener Erfahrung, dass man grafische Interfaces Python vielleicht gar nicht so wirklich machen will.

Man kann vielleicht Turtle benutzen oder so.

Ja, es ist die Frage, was ich überhaupt noch machen will, aber gut.

Aus meiner Sicht.

Ja, aber genau, es gibt verschiedene Sachen in Python dazu.

Und vielleicht mal den Martin fragen, warum benutzt du denn cute?

Oder wer bist du eigentlich überhaupt nicht?

Ja, vielleicht fängst du ja.

Genau, einfach erstmal auch nett.

Ja.

Also ich bin Martin von miaplan.de und soll ich mich kurz vorstellen?

Oder wie habt ihr euch das gedacht?

Also vielleicht kurz zu mir.

Ich habe Bioinformatik studiert, war dann fünf Jahre in der Softwareentwicklung, erst im SAP-Umfeld, dann im Bereich Automobil.

Dann habe ich das Angebot bekommen, in den Familienbetrieb meiner Eltern mit einzusteigen.

Die machen Märkte im Einzelhandel, also Fressnapf.

Und das habe ich angenommen und habe dann gesehen, wie meine Mutter dort die Dienstpläne erstellt.

Also sie hatte Personalverantwortung sozusagen, hat Dienstpläne erstellt.

Und sie hat dort Excel-Listen erstellt und hat ein Kreuz für jede halbe Stunde gemacht, die ein Mitarbeiter sozusagen eingeplant ist.

Das Ganze für damals zehn Mitarbeiter, acht Stunden pro Tag, 26 Tage im Monat kann man sich vorstellen, wie viele Kreuze sie da unterhalten.

Sie hatte dann irgendwann eine größere Sammlung an Bleistiften zugelegt, weil die halt der Reihe nach abgenutzt waren.

Und ja, das habe ich mir eine Weile angeschaut und habe mir dann gedacht, also das muss besser gehen.

Und ja, da war dann Mia-Plan geboren.

Ja, vielleicht dazu, was ist MIA-Plan?

Also, das ist ein SAS, also Software as a Service zur Dienstplanung.

Man kann damit machen Schichtplanung, Planung in der Produktion, also wenn man Maschinen hat, automatische Planung, Bereitschaftsdienste, Nachtarbeit, ja, also alles, was man sich da so wünscht oder fast alles, was man sich da so wünschen kann in dem Bereich.

Genau.

Ja, klingt interessant.

Also ich glaube, die Menge der Unternehmen, die das halt irgendwie mit Excelisten machen, das wird nicht so klein sein, das habe ich auch schon häufig gesehen.

Also ich habe ganz auch da schon die Anforderungen an sowas gehört.

Aber mich würde jetzt interessieren, warum denn mit Qt und nicht als Web-Anwendung?

Ja, ganz kurz zu Excel.

Also Excel machen, glaube ich, alle.

Also man fängt halt mit Excel an, probiert es quasi umzusetzen, was man sich halt so wünscht und irgendwann stößt man an Grenzen.

Ich glaube, das haben halt alle.

Und dann fängt man halt an, sich umzuschauen.

Ja, warum QT?

Also ich habe mir angeguckt, wie komme ich quasi zum Ziel.

Also am Anfang des Projektes war klar, ich brauche eine grafische Oberfläche.

Die soll im Web stattfinden.

Also das sollte quasi nicht auf einem Computer installiert werden.

Denn ja, also wir wollen eigentlich von überall planen.

Also nicht nur, man hat nicht immer einen Rechner zur Verfügung und meine Mutti war nicht immer am Rechner zu Hause, sondern die wollte halt auch vom Markt aus planen und was weiß ich.

Also es war klar, das muss irgendwie auch ins Web, das Ganze.

Habt mir verschiedene Sachen angeschaut.

Ihr habt es ja auch schon so ein bisschen angesprochen.

Also es gibt zig Frameworks, die man nutzen kann.

Euer Liebling ist Django, wie man unschwer raushört,

wenn man euch kennt.

Das habe ich mir auch angeschaut, kann ich ja da noch ein bisschen was zu erzählen.

Ansonsten, wenn man jetzt nicht die Bedingung Web hat, gibt es verschiedene Frameworks.

Also Kiwi ist eins davon, QT ist eins davon.

Ansonsten gibt es auch noch GTK zum Beispiel, ja, das GIMP-Tool-Kit.

Und ja, habe ich mir sozusagen alle der Reihe nochmal angeguckt und geschaut, was können die für mich leisten sozusagen.

Und wenn man die so vergleicht, also die Frameworks für den Desktop, dann kommt man eigentlich darauf, dass es zwei Frameworks gibt, die da nur in Frage kommen.

Das ist einmal QT und einmal GTK.

Das sind die einzigen, die, ich sag mal, weit fortgeschrittene Widgets bieten.

Also wenn man quasi sehr spezielle Sachen machen will und das will ich, dann kommt man eigentlich um QT bzw.

GTK nicht drumherum.

Was wäre so ein Widget beispielsweise, wo du sagen würdest, gut, das ist halt sowas, was man da bekommt.

Ja, also zum Beispiel Tabellen.

Aber nicht einfach nur Tabellen, sondern halt spezielle Tabellen.

Zum Beispiel brauchte ich Tabellen, die ein Kontextmenü können, die sollten Farben können, ich wollte Frames, farbige Frames um die Zellen zeichnen, ich brauche Callbacks, wenn ich einen Klick auf so eine Tabellenzelle mache.

Und so weiter.

Und ich habe mir das Ganze auch im Web angeschaut, also die Web-Frameworks.

Angenommen, ich hätte jetzt Django genommen.

Dann hätte ich wahrscheinlich irgendeine Art JavaScript-Tabellen-Framework genommen.

Und ich habe dort sehr, sehr lange gesucht.

Ich habe keins gefunden, was alles kann, was ich brauche.

Und dann habe ich überlegt, naja, jetzt könnte ich das vielleicht anders umsetzen, als ich mir das eigentlich vorstelle.

Also ich könnte, weiß ich nicht, die Bedienung müsste ich dann halt so umstricken, dass das irgendwie dann die jeweilige Bibliothek kann.

Und das wollte ich aber nicht.

Also ich wollte das eigentlich so machen, wie ich mir das vorstelle.

Und ja, da kam ich eigentlich nur bei QT raus.

Also QT hat sehr weit entwickelte Widgets und damit kann man, also sagen wir so, ich habe noch nichts gefunden, was man damit nicht umsetzen könnte.

Und das ist alles schon da.

Also ich brauche da nichts mehr, braucht da nichts mehr selber entwickeln, sozusagen, also was die, was die Oberfläche angeht, sondern QT bietet eigentlich von Haus aus schon alles, was man sich vorstellen kann.

Und das war quasi eine Grundvoraussetzung.

Denn ich bin ein Ein-Mann SAS.

Das heißt, ich brauche eine hohe Entwicklungsgeschwindigkeit, sonst komme ich nicht zum Ziel.

Und genau, ja, da war quasi die Bedingung.

Hätte ich angefangen, da mir ein Web-Framework rauszusuchen.

Django, ich habe ein Testprojekt aufgesetzt, schon gehabt, und habe mal geguckt, wie weit ich komme.

Aber da hat sich ziemlich schnell rausgestellt, da hätte ich sehr, sehr viel selber entwickeln müssen an Funktionalität.

Und das kam nicht in Frage.

Und wie machst du es hübsch?

Werd mal spezieller?

Was genau stellst du dir heute hübsch vor?

Also wie kannst du das ja stylen?

Also oder Sieben oder musst du da alle Widgets einzeln überschreiben?

Ist das responsive oder musst du jeweils eine eigene Applikation für verschiedene Geräte schreiben?

Oder wie lösecute das?

Ja.

Da müsste ich vielleicht erstmal sagen, wie ich das überhaupt gebaut habe.

Fangen von vorne an vielleicht, ja.

Fangen wir mal von vorne an.

Also es stand sozusagen fest, oder ihr könnt ja auch vielleicht nochmal was zu den Widgets sagen und wie man die in Django einbindet.

Aber für mich stand fest, okay, mit QT kann ich sozusagen das sehr schnell umsetzen, was ich brauche.

Jetzt hat QT aber ein Problem, das ist eigentlich ein Desktop-Framework.

Also üblicherweise würde ich also eine Software schreiben, würde die dann bundeln, also mit Pi-Installer, was weiß ich.

Und würde die dann sozusagen eine Software mir erstellen und die dann zum Kunden liefern oder würde die zum Download anbieten oder so.

Ging in dem Fall, also in meinem Fall sozusagen nicht.

Jetzt ist die Frage, wie kriegen wir quasi die Desktop-Anwendung ins Web.

Und die Lösung dafür lautet Apache Jack-Amolly.

Das ist quasi, ich weiß nicht, habt ihr das schon mal gehört?

Nein.

Das ist im Prinzip wie Remote Desktop, aber ohne Client.

Das heißt, jeder Nutzer bekommt quasi einen Account und lockt sich damit sozusagen auf meinen Servern ein und läuft damit unter einem Nutzer-Account und kann sich quasi, also ich starte dann sozusagen auf meinem Server eine Anwendung, zum Beispiel ein QT, und die kriegt dann der Anwender zu sehen.

Also die Software läuft sozusagen auf meinen Servern und der Anwender guckt sich das quasi von außen an und kann die Software auch bedienen.

Und installiert aber selber nichts.

Das heißt, es läuft rein über den Browser.

Oder anders gesagt, Apache stellt quasi einen HTML5-Client schon zur Verfügung, der einfach im Browser läuft.

Ja, ich glaube, ich habe das mal irgendwie gesehen.

Wie heißt das?

Guacamole.

Auf der DjangoCon 2021 gab es einen Talk darüber, wo auch jemand eine Shell quasi damit, also konnte man halt quasi eine Shell zugreifen, auch über einen Browser.

Richtig.

Und das war ziemlich cool.

Und das ist jetzt quasi das gleiche System, wie das funktioniert.

Ja, sehr schick.

Coole Idee.

Also theoretisch kann man damit einen ganzen Desktop in den Browser reinzeichnen.

Das ist auch die Standard-Arts der Standardanwendungsfall, aber es geht eben auch für eine einzelne Software.

Ja.

Genau.

Ja, das hat den Vorteil, dass ich QT nutzen kann.

Mittlerweile macht mir QT auch Spaß.

Also mittlerweile im Sinne von, jetzt weiß ich, wie es funktioniert.

Das heißt, das hat ein bisschen gedauert, hört sich woanders, wer die Lernkurve machen.

Ja, ja, also

die Lernkurve ist schon steil, würde ich behaupten.

Aber ich habe festgestellt, das kann eigentlich alles, was man braucht.

Also ich habe noch nichts gefunden, was das Ding nicht kann.

Und was außerdem Spaß macht, ist, also ich arbeite seit ungefähr drei Jahren damit und ich habe insgesamt fünf Bugs gefunden.

Und das ist echt wenig.

Genau.

Also da habe ich schon ganz, ganz andere Sachen erlebt.

Genau, also das ist, also macht echt Spaß, muss ich sagen.

Ja, ansonsten kann ich fast nur synchronen Code schreiben.

Ihr habt ja schon so ein bisschen gesprochen.

Die Frameworks stellen jetzt alle auf Async um, damit die mehrere, also mehr Requests quasi handeln können.

Und ich habe eigentlich den Vorteil, ich kann synchron Code schreiben.

Ja, ja, das ist natürlich, wenn man aus Entwicklersicht angenehmer schafft.

Ja, es ist deutlich angenehmer und es ist einfach.

Ja.

Ja.

Es ist sehr einfach.

Ja, schick ja.

Ich meine, ich glaube auch, dass, also ja, Qt hat halt irgendwie, das ist halt schon, das ist halt eigentlich ein sehr, sehr altes Projekt tatsächlich, aus heutiger Sicht nicht, weil ich weiß gar nicht, wann das genau gestartet ist und wann es die Firma dazu gab.

KDE ist ja da irgendwie, das war schon so in den 90ern irgendwie.

Ich weiß gar nicht, wann Qt gestartet ist, aber es muss irgendwann in den 90ern wahrscheinlich gewesen sein.

Und das ist jetzt in Version 5 oder 6 oder wie benutzt ihr das?

Ich mache gerade die Transition von 5 nach 6.

Und das ist keine komplett Open Source Lizenz, wenn ich das richtig

in Erinnerung habe.

Genau, also die haben, also das ist dual lizenziert, also es hängt ein bisschen davon ab, welche Version du nutzt.

Die aktuellste Version meine ich, ist ausschließlich kommerziell.

Und die Lizenz, also da bin ich jetzt nicht hundertprozentig drin, aber die Lizenz sagt so in etwa, wenn der Code ein Jahr alt ist, dann müssen sie es zusätzlich unter die LGPL stellen.

Also wenn man quasi die LGPL-Lizenz nutzen will, dann ist der Code recht gut abgehangen, sozusagen.

Also LGPS-Partner ist Strong Copyleft, wenn ich das richtig verstehe.

Da müsste ich jetzt meinen Anwalt fragen.

Aber ja, es ist eine relativ restriktive Lizenz und man muss schauen, dass man das, also wenn man das verwenden will und es ist, man möchte es kommerziell einsetzen, dann muss man schon ganz genau hingucken, sage ich mal.

Ja.

Ja, ja, ja, ja.

Ja, interessant, ja, ja, genau, das war MySQL hatte doch so eine ähnliche Lizenz, aber ich bin mir nicht sicher, ob sie LGPL war, wahrscheinlich eher nicht.

Ja, nee, QT irgendwie, äh, aber ich meine, dann, das ist ja ja das QT selber ist ja irgendwie in C<unk> geschrieben, glaube ich.

Wie greift man denn dann von Python?

Weil ich meine, die Anwendung ist ja dann in Python irgendwie geschrieben, hauptsächlich.

Richtig, genau.

Das ist 100% Python.

Wie kommt man denn dann an C<unk> dran?

Da braucht man ja da wahrscheinlich irgendeinen Wrapper um.

PyQt oder sowas?

Ja.

Irgendwie sowas.

Das ist, die haben eine Python-API.

Python Bindings quasi.

Python Bindings, richtig.

Und wie wird jetzt die du was?

Die kannst du auch einfach quasi in jedem Betriebssystem jetzt wieder verwenden, wenn du das möchtest.

Könnte ich, ja.

Also QT ist plattformunabhängig, also die laufen eigentlich fast überall.

Ich setze es aber unter Linux einfach ein.

Und wie machst du sowas wie Stylings und sowas?

Also wie das, was ich eben gesagt habe, mit hübsch oder sowas.

Wie gehst du davor, dass das irgendwie so ein bisschen dynamisch ist und so?

Bietet das Qt einfach alles von Hause aus?

Ja, Theming lässt sich machen mit Qt.

Es bringt aber von Hause aus schon quasi das Styling mit.

Das sieht einigermaßen nativ aus, unter jeder Plattform.

Unter Linux hat es eben den Style, den es unter Linux hat.

Lässt sich aber einfach, also man kann quasi jedes Element nochmal separat stylen, wenn man das möchte.

Das geht einfach mit CSS dann.

Wenn man das möchte.

Also die haben quasi so eine abgespeckte Art von CSS.

Unterstützen sie.

Und ja, da kann man quasi seine Elemente dann färben oder einen anderen Rahmen geben oder was weiß ich.

Ja.

Genau.

Ja, ja, ja.

Nee, interessant.

Ich glaube, ich verwende ich das letzte Mal mit Qt.

Ich erinnere mich noch dran, das ist aber schon auch wieder ein bisschen her, glaube ich, 2016 oder so, habe ich das letzte Mal irgendwie für einen Headless-Browser, den ich brauchte, weil irgendwie JavaScript ausgeführt werden sollte.

Irgendwie, das war auch damals irgendwie das Ding, was ich da verwendet hatte, auch das war auch noch diese, die, ich glaube mit WebKit, die Engine war WebKit und dann brauchte aber irgendwie braucht man noch so ein bisschen cute außenrum und dann musste ich da irgendwie Qt 5 selber kompilieren und ich erinnere mich noch, dass das ganz schön schmerzhaft war, aber.

Also ich erinnere mich auch dran, dass ich bin damals, glaube ich, über die Lizenz gestolpert.

In meinen ersten G-Versuchen, so in Python, da wollte ich unbedingt, wie man das am Anfang macht, irgendwas mit GUI bauen, dass da irgendjemand was anzeigen kann auf seinem Bildschirm.

Und dann habe ich so ein bisschen rumprobiert, auch mit Qt, aber das hat irgendwie nicht so funktioniert, wie ich das wollte.

Und ich bin ja so ein bisschen über diese C<unk>-Implementierung gestolpert und ich fand auch diese Pi-Cute nicht so super.

Und bin dann bei Kiwi gelandet tatsächlich.

Wo ich auch sagen muss, da gingen ein paar ein paar Sachen, aber das war auch alles eher so, ich weiß nicht genau.

Nicht so, wie ich das eigentlich angenehm finde.

Und dann habe ich es dann mit den Quiz wieder gelassen, beziehungsweise mit Web angefangen irgendwann.

Ja.

Ja, Kiwi.

Also Kiwi, die Widgets sind halt, also die haben nicht genug Widgets, ne?

Also da kommt man nicht weit, wenn man wirklich intensiv was damit machen will, finde ich.

Ja.

Ja, ich meine, aus meiner Perspektive wäre jetzt eher so die Frage, warum nicht, ich meine, warum macht man heutzutage überhaupt noch GUI?

Ich meine, das macht man ja, eigentlich ist doch heute alles Web.

Und sag mal so, es ist ja ein etwas anderes Modell und eigentlich vielleicht ein bisschen einfacher zu maintain, gerade wenn man jetzt eben nicht so eine größere Organisation ist, sondern eher kleiner, dann ist das ja mit irgendwie, wie macht man das, wenn Clients inkompatibel werden oder so oder unterschiedliche Versionen hat, oder das ist ja alles ganz schrecklich.

Und das ist ja so ein Problem, das man halt hat, wenn man irgendwie klassisch kleinen Server machen würde oder so oder diese alten Desktop-UI-Geschichten machen würde.

Aber ich meine, klar, wenn du das zentral laufen lässt und greifst dann nur sozusagen auf das Ding, wo das dann läuft, zu, dann hast du diese ganzen Probleme eigentlich nicht mehr.

Richtig, also ich habe ja eine ganze Menge Probleme von Hals geschafft, sozusagen.

Wo ich mir am Anfang sehr, sehr viele Gedanken drüber gemacht habe, ist, wie ist das ressourcentechnisch?

Ja, also man hat ja quasi das, oder wenn man eine Web-Anwendung hat, dann habe ich ja quasi einen ganzen Schwung von Usern und die teilen sich in der Regel keinen, also die teilen sich einen State in der Web-Anwendung, in der Regel, würde ich jetzt mal behaupten.

Und dadurch kann ich quasi die Ressourcen, sag mal, gleichmäßig auf meine Datenbank und so weiter verteilen.

Ich weiß nicht, also da kennt ihr euch eigentlich besser aus.

Ja, also ich würde sagen, der State einer Web-Anwendung liegt normalerweise in der Datenbank, aus meiner Perspektive.

Und genau, dann gibt es halt irgendwie diverse Prozesse, die halt, an die man Requests hinschickt und dann senden sie halt Responses zurück.

Und genau, ja.

So, und da hatte ich das Problem, also ich dachte es gäbe das Problem, dass ich das nicht machen kann sozusagen.

Also meine Anwendung, die ich habe, also Mia-Plan ist, hat ein State für jeden Nutzer.

Und hier hatte ich in meinem Django-Prototypen auch probiert, also diesen Zustand quasi umzusetzen und bin da aber so schon irgendwie auf eine Hürde gestoßen.

Also das scheint es jedenfalls nicht nativ so zu gehen in Django, wenn ich das richtig gesehen habe.

Allerdings habe ich auch nur vielleicht eine Woche oder so das ausgetestet.

Das geht schon.

Also du kannst halt musst ja dann Daten irgendwie modellieren und die kannst du dann in der Datenschannung speichern und dann kommst du da auch wieder dran.

Also es ist die Frage, was genau du da halten wolltest an State, aber.

Naja, also ich habe zum Beispiel relativ große NumPy-Matrizen.

Und da, und das muss auch NumPy sein, also das kann ich mir jetzt nicht irgendwie in die Datenbank reinschieben, sondern, also das könnte ich schon tun, aber das ist mir für jede Operation müsste ich mir das dann wieder rausziehen.

Das macht also eigentlich keinen Sinn.

Und da hatte ich jetzt, also von meinem drauf gucken, keine gute Idee, wie ich das mit Django überhaupt umsetzen kann.

Okay, das ist natürlich auch eine interessante Anforderung.

Also das wäre, dann wäre die Frage, okay, warum warum hast du denn Number-Matrizen?

Also ich meine, so klassischerweise hast du ja eine relationale Datenbank und dann hast du die Daten halt in einer Daten, in einer Tabelle irgendwie oder mehreren Tabellen.

Ja, vielleicht nochmal ein Planungsding.

Also was ist überhaupt das Problem?

Also du hast jetzt Menschen, die arbeiten zu Zeiten und die sich koordinieren wollen.

Ja, also Anforderungen ist im Prinzip die Folge.

Ich habe einen Sprung von Mitarbeitern und die möchte ich quasi einplanen über meinetwegen im Monat.

Also der Zeitraum ist variabel.

Und ich möchte eigentlich zu jeder halben Stunde wissen, wie viele Mitarbeiter arbeiten in Summe gerade an diesem Tag, meinetwegen an diesem Arbeitsplatz.

Das muss ich wissen und da muss ich effizient Berechnungen drauf machen können.

Und auch auf der Länge, also auf der Länge der, also wie lange arbeitet ein Mitarbeiter an diesem Tag an dieser Maschine zum Beispiel.

Und da muss ich in der Lage sein, effizient Berechnungen drauf zu machen, weil darauf basiert natürlich zum Beispiel die automatische Planung, die ich machen kann und so weiter.

Also da mache ich eigentlich sämtliche Berechnungen drauf, auch die Anzahl der Stunden, wie lange ist ein Mitarbeiter eingeplant und so weiter.

Und ja, das lässt sich am einfach, also meiner Ansicht nach am einfachsten mit Nopy machen.

Weil da lege ich mir eine Matrix an, tue die Stunden rein und dann kann ich in NumPy, sage ich, oder habe ich aber da sämtliche Operationen, die ich brauche.

Ja, also ja klar, also wenn man jetzt NumPy-Arrays hat, dann ist das natürlich so ein bisschen inkompatibel jetzt mit diesem Standardmodell, wo man in Django halt eine relationale Datenbank hat.

Ich meine, man kann das natürlich auch machen, dann ist halt die Frage, ob einem Django noch so viel nützt, weil dann kann man den ORM halt nicht benutzen.

Ich bin schon mal erfreut, dass ihr nicht sagt, ach, Mensch, da gibt es doch hier dieses Plugin, da lädst du dir einfach folgendes und dann geht es nicht aus.

Das geht tatsächlich eher nicht, denke ich.

Also was man, also ich meine, wahrscheinlich wäre dann eine Art, dass man das halt irgendwie, die Daten, die man hat, die lässt, hat man halt irgendwo einem Object so liegen oder so, in Paketformat oder sonst wie.

Und dann geht das natürlich auch, aber dann nützt einem halt der ganze ORM-Kram nichts mehr.

Die Frage wäre halt, kann man das nicht vielleicht doch irgendwie auf SQL abbilden oder geht das halt gar nicht?

Wenn es nicht geht, ja, dann kann man halt nichts machen.

Dann nützt einem.

Also klingt für mich, als wären da viele Relationen irgendwie, ne?

Also das kann man mit Sicherheit abbilden.

Die Frage ist, wie viele Schmerzen hat man dabei?

Ja, gut, genau.

Und wenn man es schon so hat und das gut funktioniert, dann ist halt die Frage, ist das, lohnt sich das oder macht man es nicht dann lieber so, dass man das einfach verwenden kann, was man schon hat, was funktioniert, ja.

Ja, da kommt es her.

Aha, interessant.

Aber also es ist auch wirklich rein Nummer, kein Pandas oder sowas, sondern einfach auch.

Auch, aber das versuche ich zu vermeiden.

Also jetzt rein Pandas ist meiner Ansicht nach nicht praktikabel, weil ganz einfach die Importzeit beträgt drei Sekunden.

Ja, ja, ja.

Das ist völlig inakzeptabel.

Das soll ich nur einmal importieren.

Aber ja, aber selbst wenn ich den Import an die Startzeit verschiebe, also ich kann, oder in die Laufzeit, ist ja egal.

Drei Sekunden sind an keiner Stelle akzeptabel.

Okay, ja gut.

Und da bleibt höchstens die Variante, hier die Alternativen zu nehmen, die es inzwischen gibt.

Jetzt müsste ich Polars, glaube ich, die aktuelle Entwicklung in Rust, wenn mich nicht alles täuscht.

Das habe ich mir noch nicht in der Tiefe angeguckt.

Ich nehme mal an, die Importzeiten sind da besser.

Ich weiß aber nicht, ob Polars schon alles kann, was ich da brauche.

Ja, das ist ja jetzt erst am Anfang, genau.

Ja.

Ja, interessant.

Ja.

Ja, also das ist natürlich auch etwas, was man halt in Python gut machen kann und sonst wahrscheinlich auch eher nicht hat, dass man halt diese Numpai-Geschichte da direkt irgendwie verwenden kann.

Ja.

Also NumPy ist eine der besten Bibliotheken in Python, würde ich sagen.

Ja, ja.

Da kann man echt so viel rausziehen und da ist so viel schon da und es ist vor allem verdammt schnell.

Ja.

Aber wie ist denn dann das, also wenn wir jetzt zu dem Qt, da, also die Bindings, ist das dann halt, da muss man dann Camelcase verwenden?

Wahrscheinlich ja, ne?

In QT6 nicht mehr.

Da haben sie es quasi normal gemacht.

Aber naja, man gewöhnt sich dran, sag ich.

Ja, gut, klar.

Es ist jetzt auch nicht so, es ist auch kein Weltuntergang, wenn ich jetzt für die Calls dann eben Camelcase habe.

Aber ja, schön ist es nicht, das stimmt.

Ja, so die Fußläge nach oben gekriegt.

Ja, gut, ich meine, ich mache ja auch andere Sachen aus TypeScript und so, da mache ich auch Camel Case, aber wenn man in Python ist, dann finde ich das mal, wenn die Kombination.

Manchmal Snack Case ist manchmal Camel Case, dann ist es ein bisschen.

Aber ja, gut.

Ja, ja, interessante Geschichte.

Aber wie ist das denn jetzt, wenn jetzt mehrere Leute auf die Applikation zugreifen?

Genau, also ich war ja stehen geblieben, also ich habe mir Sorgen gemacht sozusagen, dass das nicht skaliert.

Und das scheint aber nicht so schlimm zu sein.

Also nein, scheint relativ gut zu sein.

Also ich habe mir vor allem Sorgen gemacht um die Bandbreite.

Und da muss ich sagen, das ist gar kein Problem.

Also das kostet tatsächlich fast keine Bandbreite und würde sogar behaupten, das ist ähnlich einer Web-Applikation.

Hm, wie übertreibt denn dieses Gracamoli-Daten, ist das nicht ein Bild oder?

Nein.

Also das kommt darauf an.

Das unterstützt mehrere Backends.

Man kann zum Beispiel VNC nehmen.

Man kann aber auch XRDP nehmen.

Und je nachdem, wie effizient das implementiert ist, ist es gut.

Und im Fall von XRDP ist es gut.

Und da werden also keine Bilder mehr übertragen.

Also da wird vielleicht ein Frame am Anfang übertragen und dann werden nur noch Deltas übertragen.

Okay, ja.

Also da entsteht tatsächlich nicht viel Traffic.

Und was den Speicherbedarf angeht, da bin ich ja selber für verantwortlich.

Und habe das selber in der Hand.

Aber es ist denn ja schon so, dass du quasi eine Applikation pro Nutzer irgendwie starten musst, mehr oder weniger.

Richtig.

Genau, das ist schon so.

Aber ich habe mir das durchgerechnet, also das funktioniert.

Also ich kann ja auch selber mehr oder weniger bestimmen, sage ich mal, wie viel Speicher das Ganze frisst.

Und wenn ich mir halt die Bibliothek reinziehe, die 500 Megabyte beim Import frisst, dann kann ich die halt nicht nehmen.

Ja, auch interessant, braucht man, und genau, was mich auch noch interessieren würde, um diese grafische Darstellung halt, die muss ja dann irgendwie schon irgendwo gerendert werden.

Das heißt, du brauchst auf dem Server hast du dann quasi auch einen X oder irgendwie sowas?

Genau.

Leider ist es noch ein, also es wird ein X-Server pro Anwender gestartet.

Und es ist leider noch ein X-Server und jetzt komme ich gerade nicht auf den Namen.

Was war die Weiterentwicklung davon?

Oh, das war das.

Was kam nach X?

Wayland.

Wayland, genau.

Wayland, richtig, genau.

Also es wird daran gearbeitet, dass das Ganze Wayland-kompatibel wird, aber ist noch nicht so weit.

Aber meine Hoffnung ist ja, dass X gibt es ja jetzt schon, ich weiß nicht, 20 Jahre, 30 Jahre.

Also ich denke, es wird es auch noch eine Weile geben, dass da noch genug Zeit ist, das zu portieren.

Ja.

Und dann ist Map quasi ein User, der das von außen benutzt, eigentlich mehr oder weniger auf den User im Unix-System.

Ja, nicht eigentlich, sondern tatsächlich.

Tatsächlich, ja.

Ja.

Schauen wir hier rum.

Ah, das ist, Dominik hat mir gerade irgendwie ein Plan auf dem Telefon aufgemacht und da flockerte das.

Das weiß ich allerdings aber nicht, ob das jetzt irgendwie.

Ja, also das Ganze läuft auf Tablets und Telefonen, aber das ist nicht meine Zielgruppe eigentlich.

Also es funktioniert.

Man kann damit auch planen, man kann sogar Tastatureingaben und alles machen.

Da gibt es eine Tassenkombination dafür, wie das geht.

Wenn man in der FAC nachguckt, steht das da drin.

Aber eigentlich ziele ich auf den Desktop-Anwender.

Und eigentlich ist es nur schön, auf den Desktop zu planen.

Ich glaube, keiner möchte wirklich auf dem Handy seine 32 Mitarbeiter planen.

Also ich weiß nicht, ob es da irgendeine Software gibt, die das gut macht.

Wenn, dann Chapeau.

Aber ich ziele da nicht drauf.

Also ich habe es nicht davon.

Also ich habe tatsächlich so ein paar Ideen an der Stelle auch schon durchgespielt, weil ich diese Anforderung wirklich auch so ein paar Mal gekriegt habe.

Auch so Business ist es heraus, die es halt wirklich brauchten.

Die es ganz interessant fanden.

Also nicht raus.

Muss ich eigentlich nochmal umsetzen.

Irgendwann im nächsten Leben, wenn ich mehr Zeit finde.

Ja, ja, ja.

Aber ich meine, man kann sich schon, also so gerade im Büro-Feld haben, die sitzen die Leute ja schmeißen, schon vom Rechner, dann kann man dann schon von ausgehen, dass das so funktioniert.

Ja, ja, ja.

Ich meine, das ist halt ganz anders, als man das sozusagen so kennt, aber ich meine, wenn man so ein bisschen drüber nachdenkt, dann ist das eigentlich gar nicht so blöd.

Das ist schon interessant.

Also der größte Vorteil, den ich sehe, ist wirklich die Entwicklungsgeschwindigkeit.

Ich brauche, ich habe kein HTML, ich habe kein CSS, ich habe kein JavaScript, ich kann ein reines Python schreiben und kann mein Feature deployen.

Ja.

Ja, ja.

Und ich mag Python.

Und ich mag weniger CSS und JavaScript, das mag ich nicht so gerne.

Also ich kann es, ich komme nicht drum rum, also ich mache das auch, aber nur wo es wirklich nötig ist.

Ja.

Ja, ich überlege gerade, man hat sich so ein bisschen daran gewohnt.

Also ich finde zum Beispiel mittlerweile schwierig, das von den nicht mit CSS irgendwie vielleicht auch ein bisschen JavaScript zu stylen, weil mir so ein paar Sachen dann immer fehlen.

So diese dynamischen Sachen, an die man sich dann doch irgendwie dran gewöhnt, so Headless UI oder so.

Das geht mir schon auf die Nerven, wenn ich jetzt in Django das ohne Rest-API benutzen möchte, sondern die Templates einbaue.

Das ist manchmal schon immer so ein bisschen struggling, weil ich halt da schon relativ viel auf Vue.js klebe.

Ja, aber das ist ja kein Problem von.

Das ist einfach das Ökosystem.

Die Frage ist halt, welche Leute haben sich schon wie viel auseinandergesetzt, mit Dingen zu entwickeln, die das schön, einfach und pretty zu benutzen machen.

Du meinst, achso, ja gut, okay.

Also wenn du aus der Entwicklersicht drauf guckst und dir dann überlegst, okay, wenn ich jetzt.

Schnell Produktivität maximal anpassen.

Und mit irgendwie UI-Sachen, wo ich mir meine, wenn ich quasi fürs Web eine Applikation so schreiben will, wie ich das sonst mit PyQt machen würde.

Oder mit Qt, welches, was nehme ich denn da?

Dann landest du wahrscheinlich bei den SPAs und dann landest du halt auch irgendwie bei irgendwas von den großen UI-Frameworks, die es halt für JavaScript gibt, weil genau, da ist halt schon am meisten Arbeit reingegangen.

Also ich bin mir natürlich dann so ein bisschen so ein Klotzansbein.

Naja, aber dafür habe ich natürlich auch das ganze Ökosystem mit damit.

Ich bin halt nicht ganz alleine.

Also mein Problem wäre jetzt bei Qt in Python mit den Bindings.

Ich muss es halt alles selber bauen, ne?

Also vom Scratch irgendwie.

Ich muss mir selber komplett überlegen, wie das aussehen muss.

Ich frage mich gerade so ein bisschen wie, also wie überhaupt so ein.

Was ich auch noch gerne von Martin wissen würde, wäre, wie überhaupt so ein UI strukturiert ist so prinzipiell in Python.

Also von der Struktur her.

Also ich glaube, das ist gar nicht so groß anders, als wenn man mit Django das machen würde.

Also es gibt ein Event Loop.

Und ja, eigentlich dreht sich alles um das Event Loop.

Und wenn man was Asynchrones braucht, dann bietet QT da auch noch was Asynchrones.

Das ist im Wesentlichen eine Python-Klasse.

Ja.

Was interessiert dich speziell?

Also mich interessiert vor allen Dingen das UI irgendwie.

Also, ne?

Also wie baue ich zuerst mir einen Rahmen und dann da verschiedene Container rein oder mache ich das irgendwie über so Floating-Geschichten oder mache ich das alles statisch?

Achso, achso, jetzt habe ich dich falsch verstanden.

Ich dachte, du meintest das Design der Python-Applikation, aber du meinst tatsächlich die Oberfläche an sich.

Ja, also QT hat unterschiedliche Wege, wie man das machen kann.

Ich habe da auch noch nicht alle bis ins Detail ergründet, tatsächlich.

Auch nach drei Jahren noch nicht.

Aber der Standardweg ist, man programmiert sich sozusagen seine Oberfläche.

Also ich sage, ich möchte einen, also es gibt verschiedene Frame-Arten, zum Beispiel einen horizontalen Frame, einen vertikalen Frame oder was Tabellenartiges oder was Formularartiges.

Und dort grupiere ich mir quasi meine Elemente rein.

In diese Boxen, sag ich mal.

Und das Ganze ist responsiv, wenn man das will.

Auch animiert ist?

Wie bitte?

Auch animiert.

Man kann alles.

Du kannst animieren, du kannst also kannst ja mal die Widgets angucken, die es so gibt.

Animiert, du kannst dir Schieberegler machen, du kannst dir Knöpfe machen in bunt oder in blinkend oder in Warband.

Ja, das geht alles.

Woran ich eben denken musste, ist halt, ich glaube, es ist halt sehr stark davon abhängig, ob das jetzt eine gute Idee ist, sozusagen, dass man das einfach so nehmen kann, die Virtuals, oder wahrscheinlich kann man sie ein bisschen stylen oder ob das jetzt besser wäre, das über CSS und JavaScript zu machen, hängt halt wahrscheinlich sehr stark von einem Use Case an.

Ja, ja, also die Frage ist halt, wie die Arbeit muss ich jetzt da noch reinstecken, um ja so ein komplettes Konzept auszudrücken.

Aber wenn dein Use Case ist, du willst irgendwas Kompliziertes machen, aber letztlich ist es nicht so wahnsinnig wichtig, dass das jetzt zu deinen Brandfarben passt, weil das ist halt gar nichts, was jetzt Customer-Facing ist, sondern es ist halt irgendwie ein Ding, was Leute benutzen, um irgendwas zu erreichen, aber das ist nie nach außen hin sozusagen.

Wer ist denn ein Recorder?

Ja gut, natürlich schon die Leute, die das benutzen, aber das ist halt nur intern.

Das würde ich anders sehen, mit dem nur intern.

Ja gut, aber warum, ja, okay, aber da würde ich jetzt denken, an der Stelle macht es halt Sinn, vielleicht was zu verwenden, womit du komplizierte Sachen hinbekommst, die du vielleicht brauchst, weil das ein kompliziertes Problem ist.

Aber die Anforderung, dass du das jetzt irgendwie besonders hübsch oder so auf dich angepasst dargestellt hast, also dass es so aussieht, das ist halt nicht so wichtig.

Selbst wenn ich das so hübsch hinbekomme, ich frage mich, wie viel Aufwand ist, das so hübsch hinzubekommen, ja?

Ja, vielleicht wäre das ganz schrecklich viel Aufwand, aber wenn dir das egal ist, dann musst du es nicht machen.

Naja, also du meintest gerade, entweder ich mache es mit CSS oder ich mache es mit QT, da stimmt nichts.

Was meinte es nicht mit CSS oder bei QT, sondern ich meinte sowas wie mit den ganzen Frameworks, die ich habe.

Die ich halt ja gerne muss, keine Ahnung, Tailwind oder sowas, damit ich halt schneller produktiv finde, Utility oder so, Utility Klassen einbauen.

Aha.

Also weil wenn ich das ganze CS dann immer selber schreiben muss und dann muss ich mir erstmal überlegen und dann muss ich erstmal so ein paar Boxen bauen, dass das alles so passt, dann.

Na, kommt drauf an, also QT hat auch noch einen Designer.

Wenn du das Projekt nicht kommerziell nutzen willst, kannst du diesen Designer nutzen.

Aber wenn ich das nicht mache, dann kannst

du es quasi nicht.

Kannst du den Designer nutzen, dass es quasi mit Ziehen und Ablegen quasi.

Erinnere ich mich.

Das hatte ich genauso.

Wie man

das früher von, ich glaube, Visual Basic da war das so ähnlich schon.

Kann man auch, wenn man will.

Der war auch sehr hübsch.

Nein, ich hatte tatsächlich, glaube ich, den angefangen auszuprobieren und dann bin ich darüber gestolpert, dass man das irgendwie mit der Lizenz eben nicht benutzen darf, wenn man das machen lasse.

Okay.

Ja, ja, ich meine, das machen ja auch die ganzen, oder ich meine, ich kenne jetzt die iOS-Seite besser, aber halt da X-Code und so, da gibt es ja auch solche Dinge, wo du dann halt dann grafisch dann die ganzen Elemente irgendwie sozusagen, selbst dann kannst du sogar Linien irgendwie dahin ziehen und dann werden dann halt irgendwie Event-Listener hinzugefügt oder keine Ahnung, oder dann wird halt ja genau, damit geht das wahrscheinlich auch irgendwie.

Aber naja, ich könnte mir schon vorstellen, dass, also du kannst jetzt zum Beispiel nehmen wir an eine iOS-App, da kann ich es halt, weil ich nehme mal an, dass es bei Qt genauso ist.

Sozusagen, damit kannst du im Grunde alles machen, aber wenn du jetzt eine iOS-App so hinkriegen willst, dass sie genauso aussieht, wie du das haben möchtest, ist das halt eine Menge Arbeit.

Ja, genau.

Also und zwar wahrscheinlich mehr Arbeit, als wenn du eine Webseite so aussehen lassen möchtest, wie du das aussehen lassen möchtest.

Das ist das so ein bisschen, also ohne dass ich jetzt angreifen möchte, aber das ist so ein bisschen mein Problem mit diesen UT-Sachen oder meine Kritik daran.

Also weil ich glaube, dass das wirklich schwieriger ist, das richtig schön hinzubekommen.

Ja, aber jetzt nochmal, jetzt versuch mal in HTML und CSS eine Tabelle so hinzukriegen mit all den Widgets und Features, die du vielleicht haben möchtest für deinen Use Case.

Dann hast du an der Stelle ein Riesenproblem.

Das geht ja auch nicht gut.

Ja, also aus meiner Perspektive, mein Branding mache ja ich.

Von daher hatte ich das Problem nicht.

Dazu kann ich dann entsprechend auch nicht so viel sagen.

Also was ich sagen kann ist, es lässt sich jedes Element mit CSS stylen, wenn man das will.

Ja, ich glaube, so groß und unterscheiden tut sich das gar nicht versus Django.

Ah ja, okay.

Mit dem Unterschied natürlich, wenn man sein geliebtes Framework nutzen will, Tailbind, was weiß ich.

Das funktioniert natürlich anders.

Aber gut, wenn man sich ein anderes Framework auswählt, dann sind halt Dinge anders, ja.

Ja, ja, also was ich halt meine, du kannst halt jetzt, wie wir das bei unserem Podcast gemacht haben, ich lasse ihm das erzählen habe, Bootstrap importiert und sonst nichts tun für das Design, weil das nicht wichtig ist.

Ja, ja, genau.

Also da habe ich das ja auch im Grunde genommen.

Ja, ich glaube auch, das ist der Grund, warum halt Bootstrap quasi so viel verwendet wird in internen Tools.

Weil da ist es halt oft egal.

Es ist halt wurscht, ja.

Also wie das jetzt aussieht, es muss halt bloß irgendwie halbwegs bedienbar sein.

Und das kriegt man mit Bootstrap ja schon hin.

Es sieht halt nicht so toll aus.

Aber ja.

Genau.

Ja, ja.

Ich weiß es nicht so genau.

Es ist immer, das ist alles eine, das ist so wirklich so ein bisschen.

Also mich hat das schreiendeweise.

Was möchte man am Anfang immer machen?

Wenn man jung ist und Software entwickelt will, möchte man Spiele programmieren.

Das geht mit Cute wahrscheinlich schon ein bisschen besser als mit Web.

Aber auch da bin ich mir nicht sicher, ob das die richtige Idee ist, irgendwie das so zu betrachten.

Nee, ich glaube, da würde, da würde es eine Spiele.

Wir können auch noch was machen willst.

Also ob du eine 3D-Intel möchtest oder halt nicht.

Also ob der halt dann eine zweidimensionale, weiß nicht, kann man Fensteransicht sagen zu Cute, reicht.

Achso, ja cool.

Also für Spiele wäre jetzt QT nicht mal eine erste Idee.

Aber kommt sicherlich aufs Spiel an.

Ja, klar auch.

Also nur weil man dann Python macht.

Ja, genau.

Das geht wahrscheinlich gut.

Ja.

Da kam ich mit Kiwi schon ein bisschen weiter tatsächlich.

Also es war auch so eine Art Bürosimulator, weißt du, ey.

Ja.

Ich habe einen Fantasy-Manager für unsere Eishockey-Runde gebaut.

Ja, gut, sowas.

Das hat wundervoll funktioniert.

Ja.

War sogar hübsch in Kiwi.

Aber ja, ich glaube, man will das nicht.

Bloß fummelig.

Ja, aber was, ähm, was mich auch nochmal interessieren, würde so rein so ressourcenverbrauchmäßig, wenn ich jetzt für einen User so eine Applikation starte mit Qt, da habe ich schon das Gefühl, also wahrscheinlich so ein paar MB wird die dann schon einen Hauptsprecher brauchen oder so.

Die muss ja dann auch die ganze Zeit laufen, obwohl die muss eigentlich nur so lange laufen, wie ein Benutzer sie tatsächlich benutzt.

Dann kann man irgendwie den State irgendwie so aus serialisieren und erst beim nächsten Mal, wenn jeder Nutzer wiederkommt, dann muss man das halt irgendwie wieder sich irgendwo herholen.

Genau so ist es.

Ja, aber tatsächlich, solange ein Nutzer irgendwie quasi da drauf guckt, also die Frage eingeloggt ist, oder ich weiß nicht, wie man das beschreiben kann, solange irgendwie eine Session aktiv ist, wie auch immer, brauchst du halt diesen Hauptspeicher.

Ja, genau.

Ja, okay.

Dann bist du, wobei da auch einiges im Shared Memory sich befindet.

Ja, die ganzen

Bibliotheken wahrscheinlich, ja.

Das macht Python von sich aus schon.

Das heißt, man hat jetzt nicht komplett den Overhead von einem Nutzer auf alle Nutzer, sondern da wird noch einiges geteilt.

Aber ja, prinzipiell schon.

Ja, weil da bist du natürlich dann wahrscheinlich ein bisschen ineffizienter als eine Webanwendung, die halt nur das, wo es dann halt einen Prozess gibt, der halt dann viele Requests von unterschiedlichen Benutzern.

Genau, also speicherintensiver ist das schon.

Wobei es nicht so wichtig ist, dass der Speicher schnell beschrieben werden kann.

Also mit anderen Worten, es muss nicht zwingend RAM sein.

Ah, okay.

Was einem die Möglichkeit gibt, ein Swap-Laufwerk anzulegen, das irgendwo hinzutun, wo es einen relativ zügigen Zugriff hat.

Und ja, da geht es auch.

Ja, und SSDs sind jetzt auch nicht so mehr so super langsam.

Genau, also eigentlich sind wir mit der Swap-Variante unbegrenzt im Hauptspeicher.

Ja.

Fast.

Ja, ja, ja, ja.

Nee, durchaus interessantes Modell.

Ja.

Und ja, ich meine, was, äh, wenn man jetzt aber die, für die Benutzer ist es ja auch so ein bisschen, die kommen aber gut damit klar und nehmen das so an oder hörst du da häufiger das so höher, warum das ist irgendwie komisch?

Ich weiß nicht genau.

Also bis jetzt habe ich tatsächlich dazu noch gar nichts gehört.

Ah, okay.

Interessant.

Also es scheint einigermaßen intuitiv

zu sein.

Vor allem, weil man es ja auch vom Desktop schon kennt.

Ja.

Also die Art der Bedienung, sage ich mal.

Gehen denn da wirklich alle?

Also jetzt stelle ich mir natürlich so, stellt sich mir die Frage, wie ist das denn jetzt mit Tastaturkürzeln oder weiß ich nicht, rechter Mausklick oder so.

Das muss ja jetzt alles wie ein Browser durch.

Der Browser lässt ja jetzt nicht alles durch.

Manche Sachen sind ja auch, quasi fängt der Browser ja wahrscheinlich schon ab, um, wenn man ein anderes Hub auswählt oder das Fenster zumacht oder so, das geht dann ja gar nicht bis auf die andere Seite.

Aber ich weiß jetzt auch nicht genau, was da möglich ist und das nicht.

Ja, also hätte man das selber entwickeln müssen, den Client in JavaScript, hätte man wahrscheinlich mehrere Jahre gebraucht.

Muss ich aber nicht.

Der ist schon fertig.

Und der kann tatsächlich alles, was man sich unter Desktop so vorstellt.

Also Rechtsklick ist kein Problem, Tastatureingaben sind kein Problem, Tastaturkürze sind kein Problem.

Also das ist eigentlich alles da und wird von Firefox und von Chrome supportet und damit eigentlich von 90% von allem, was es sage so gibt.

Ja, ja, ja.

Ja, das heißt, man kriegt auch gar nichts, also aber es ist schon in einem Browserfenster, muss es halt sein.

Richtig.

Aber ansonsten kriegt man eigentlich gar nicht mit, dass es wirklich, dass es ein Browser ist, sondern dass es eigentlich eher verhält sich wie eine native Applikation.

Verhält sich so, als ob man die Anwendung lokal auf dem Rechner hätte.

Auch ja, Copy und Paste, wahrscheinlich bei Text kein Problem.

Wenn ich jetzt irgendwas da reinziehe oder so, okay, dann passiert wahrscheinlich komisch dabei.

Genau, es gibt Dateitransfer, es gibt, wenn man will, sogar Audio.

Ja, schick.

Ich glaube, dieses Quacamoli muss ich mir auch mal angucken.

Scheint ja schon sehr interessant zu sein.

Ja, ja.

Ja, lass mal überlegen, was könnte man sich denn noch so vorstellen, was interessant sein könnte bei diesem.

Also gibt es, ist das der Client selber, der Python, äh, der Python-Rapper um Qt kommt selber auch von wie hat, äh, ich weiß nicht, wie hieß denn diese Firma nochmal, die das, die Qt baut?

QT Foundation meine ich.

Qt Foundation.

Ah ja, na gut, ich weiß nicht mehr, da war ja auch eine lange Zeit, vielleicht gibt es die Firma auch nicht mehr, keine Ahnung.

Foundation klingt jetzt irgendwie eher nicht mehr nach.

Aber genau, von denen kommt halt auch, die kommen die Python-Bindings, weil ich habe irgendwie gehört, PySite gibt's oder genau.

Ach, das sind die dann, ja.

Wenn ich QT sage, dann meine ich PySide.

Ah, okay.

Tatsächlich.

Also es gibt unterschiedliche Ausprägungen, wie man QT nutzen will kann.

Und ja, ich habe mich für PySite entschieden.

The QT Company.

Ah, okay.

Hier gibt es ja noch so ein paar andere Sachen, ne?

Vielleicht wollen wir die noch kurz erwähnen.

Also Kiwi haben wir jetzt schon, glaube ich, im Endeffekt.

Da gibt es noch WXPython und kennt jemanden GTK-Bindings für Python?

Genau, also GTK würde ich sagen, ist so das zweite große Framework, was man da nutzen kann.

Was nicht ganz, aber so ungefähr auf Augenhöhe.

Naja, andere würden wahrscheinlich was anderes sagen.

Also es ist auf Augenhöhe mit QT und ja, die Widgets sind ähnlich weit gediehen.

Kann man das ja quasi aussuchen.

Aber würdest du dein, du würdest ja wahrscheinlich alles, dein ganzes User-Interface und auch deinen Desktop komplett mit Qt bauen oder mit GTK.

Dafür habe ich GTK noch nicht zu sehr in die Tiefe getestet, um das sagen zu können.

Aber ja, also es scheint, es scheint ähnlich weit zu sein.

Aber dafür habe ich es mir nicht genug angeguckt, um jetzt speziell sagen zu können, das geht damit und das geht damit nicht.

Dann gibt's noch einen Rapper da irgendwie drum, PiSampleGUI, der mit den einfachen Sachen irgendwie dann auch gehen, ein schneller oder sowas oder noch mehr High-Level-Iterface?

Kenne ich auch nicht im Detail, PiSample GUI.

Das macht also einiges auch über, ich glaube, Q, da kann man dann die oder WX Pyisen.

WX Python wäre noch so ein Ding.

Habe ich jetzt auch mal irgendwie mal kurz ausprobiert, aber es war so mittelhübsch.

Ja, habe ich ja schon als Sache nichts davon gehört.

Ja, genau, aber gegen wohl ein paar Sachen.

Ja, ne, ich würde sagen, es ist immer noch so Python-GUI, ist immer noch so ein bisschen.

Ja, wobei ich tatsächlich, also ich würde schon die Ansicht vertreten, also ich meine, auch wenn das alles schon eine interessante Geschichte ist und aber ich habe schon so das Gefühl, dass so diese Desktop-UI-Geschichten so ein bisschen.

Also vielleicht riechen sie auch noch komisch.

Also ich bin bei der Ansicht, da könnte schon so ein bisschen tot sein, weil.

Was ist mit BWare?

Ja, ja, genau.

Aber da ist halt, also das, das ist, also das würde ich auch so sehen, also das ist Russell Keith McGee, der hat ja auf der auf irgendeiner PyCon eine Keynote drüber gehalten.

Irgendwie, was sind die größten Gefahren für Python?

Oder Black Swan, irgendwas war im Titel.

Dem würde ich mich durchaus anschließen.

Also was für Python richtig gefährlich ist, ist, dass halt auf mobile läuft.

Dass das nicht auf Mobile läuft, weil tatsächlich irgendwie Computer werden verdrängt.

Also die Telefone sind inzwischen, also ich würde mal sagen, ein durchschnittliches iPhone ist wahrscheinlich schneller und leistungsfähiger als ein durchschnittlicher Desktop-Rechner.

Ja, du stellst halt einfach irgendwo so ein Tablet hin und dann gibt es halt da ein paar Knöpfchen drauf und dann muss das halt dann funktionieren.

Ja, und Kinder wachsen damit auf, die kennen das gar nicht mehr, die denken sich so, was sind das so komische große Dinger da, seltsam, was ist das?

Kann man die swipen?

Ja, genau, tippen dann auf den Bildschirm, dann passiert nichts, das ist kaputt.

Also das ist ein Problem, weil in zehn Jahren oder 20 Jahren wird das wahrscheinlich keiner mehr benutzen.

Halte ich für eine steile These.

Ja, gut, aber ich meine, das ist nur so ein, das ist ein Risiko, ja.

Also ob das jetzt so eintritt oder nicht, ist natürlich klar, wie hoch ist das eigentlich?

Wenn man das benutzt, muss man wahrscheinlich schon relativ viel damit auskennen, irgendwie.

Ja, aber also wie auch immer, aber dass es da ein Risiko gibt, würde ich schon sagen, einfach deswegen, weil Python da halt nicht läuft.

Es läuft da nicht.

Und das ist ein Problem.

Und jetzt muss man entweder irgendeinen Weg finden, wie man Python da, wie man sozusagen es schaffen kann, dass man Python entwickelt und dann halt aber auch eine iOS oder Android-App hat.

Und das ist halt genau, Beware macht das halt genau.

Sondern diverse Komponenten, die dafür nötig sind.

Ja, letztlich macht es sowas ähnliches, was halt React Native oder so auch macht.

Das ruft schon die echten UI-Funktionen dann auf von den Frameworks der entsprechenden.

Also kompiliert runter quasi auf Kotlin?

Nicht ganz, nee, es kompiliert, es kommt, ja, also es gibt unterschiedliche Komponenten und die machen unterschiedliche Sachen, aber letztlich, es gibt auch Wrapper um die echten Funktionen sozusagen drumrum und die werden dann aufgerufen.

Und ja, also.

Das ist interessant, wäre auch interessant zu wissen, wie React das eigentlich macht und dann gibt es ja noch irgendwas wie Jonos oder Capacitor oder so.

Ja, es gibt dann Teile, die sind halt komplett nativ und dann Teile kommen dann halt aus dem, kann man aus dem Web nachladen, man kann JavaScript ausführen und es ist, ja gut, oder Elektron macht das ja auch so.

Ja, also wie gesagt, ich glaube, da sind wir auch noch nicht, auch noch nicht durch.

Das war auch ganz interessant.

Ich habe mich jetzt, ich war letzte Woche Donnerstag, auf dem Treffen der Java-User Group, das, äh, Java Rhein-Juke, die Java-Java-User-Group.

Was hat sich denn dahin verschlagen?

Ja, ich dachte, ich muss mich mal weiterentwickeln und dann dieses Python entwickeln.

Das kann ja wohl nicht, das hat keine Zukunft, den muss man mir Java angucken.

Nee, ähm.

Ich bin da hingegangen, weil der Vortrag da hat mich irgendwie, ist mir aufgefallen, dass da Stefan Tilkoff und Ebert Wolf, die machen so Software, Software-Architektur, TV und die machen auch Podcast und die sind beide bei Induecue und die haben auch schon viele interessante Stefan Tilkoff ist oft zu Gast in anderen Podcasts, gerade letztens war bei der Programmierbar und hat da über Architektur gesprochen, die machen vieles Software-Architektur, die sind auch so, das ist so eine der Firmen, wo man hingeht, wenn man

jetzt ein großes Problem hat, ein großes Projekt und man möchte jetzt irgendwie so das einem mal wirklich erklärt, wie man das denn so angeht und wie man das besser machen kann, dann ist das so eine der Adressen, zu denen man gehen kann und wahrscheinlich eine der redoren Adressen.

Und ich höre dem immer gerne, ich höre zum Beispiel Stefan Tillkoff immer gerne zu, weil ich finde, der kann das immer schön erklären, was so die Probleme sind, die man da hat.

Und ja, deswegen bin ich dahingegangen.

Und da haben sie haben geredet über, wie sah das eigentlich vor zehn Jahren aus, wie sieht es heute aus, haben sich die Probleme irgendwie verändert in IT?

Welche Sachen sind besser geworden, welche Sachen sind immer genauso wie vorher?

Und genau, da, oi, jetzt bin ich ja schon wieder abgeschweift.

Da war auch einer, der machte so ein bisschen Elixir und auch kein Java.

Und der meinte, in letzter Zeit macht er immer mehr Dart, weil Dart für das ist diese Sprache von Google für so, das sollte, glaube ich, auch mal irgendwann Webgeschichte werden, aber jetzt hat sich so halt eine Nische gefunden.

Man kann damit halt Mobile-Apps irgendwie oder Apps für Android-Telefone oder iOS-Geräte entwickeln.

Das ist eine eigene Sprache.

Flutter ist halt das Ding, was dann ein UI macht.

Und das braucht im Grunde nur irgendwie einen Canvas, wo es halt irgendwie SVG reinrendern kann oder so, glaube ich.

Und macht dann eine UI komplett selber.

Also das ruft nicht irgendwelche Funktionen, nativen UI-Funktionen auf von dem entsprechenden irgendwie Gerätehersteller, also sondern das zeichnet alles selber.

Also alle Buttons und Dinge und so werden halt einfach irgendwie tatsächlich in den Canvas reingezeichnet.

Und da Canvas überall da ist und man da irgendwie beliebige Dinge reinzeichnen kann, kann man halt alle Sachen gleich aussehen lassen auf allen Geräten damit.

Und halt auch relativ, und es ist halt einfacher zu entwickeln, als wenn man jetzt irgendwie, das haben ja diese statischen Premiersprachen oder statistierten Premiersprachen, da ist halt immer so, ja, ich meine, gut, mit Kotlin ist es schon ein bisschen besser geworden, aber Java ist halt schon, also für Android, das ist halt schon sehr verbos und man muss halt sehr viel Boilerplate schreiben und auch Swift ist halt vielleicht ein bisschen besser, aber so wahnsinnig viel besser, auch nicht, ist auch relativ schrecklich.

Und ich meine, mein böser Schatz an der Stelle wäre ja immer so, naja, Software-Architektur hat mich auch lange nicht interessiert, weil man schreibt ja in Python oft nicht so große Sachen, weil man muss ja nicht so viel schreiben.

Und wenn man in Java für Hello World halt schon tausend Zeilen irgendwie Boilerplate schreiben muss, dann muss man sich Gedanken um Software-Architektur machen, einfach weil, um das Boilerplate-Zeugs was zu organisieren.

Und ja, das muss man mit Dart auch nicht so und dann hat man dann eine Alternative, die vielleicht ein bisschen einfacher zu verwenden ist.

Und das setzt sich gerade durch.

Also ich glaube, das, was der sagte, war, irgendwie inzwischen sind fünf, also der Marktanteil von Flutter ist halt inzwischen größer als der von allen anderen Sachen, die es da halt auch gibt, mit Elektronen und keine Ahnung, die ganzen, als von allen anderen zusammen.

Und das ist natürlich.

Also wenn man zum Beispiel eine App machen will für Android und iOS, dann muss man es halt nur einmal schreiben, das ist der große Vorteil.

Es bringt aber, wenn man es länger verwendet, doch auch so das eine oder andere Problemchen mit sich, wo man am Anfang nicht unbedingt von weiß.

Ja, also ich meine, das ist halt immer ein Beispiel, glaube ich.

Also ich hatte zum Beispiel, also ich habe eine App oder mehrere in Flutter entwickelt.

Und es gibt dort ein Paketsystem sozusagen.

Also man kann sich dort Zusatzfunktionalitäten, ähnlich wie in Python mit Libraries, kann man sich oder Packages kann man sich dort auch reinladen sozusagen.

Das Problem daran ist so ein bisschen, dass die oftmals halt von externen Entwicklern kommen, so von dir und mir.

Und externe Entwickler dann nach anderthalb Jahren gerne mal die Lust an den Projekten verlieren.

Und dann hat man so Unmaintained Dependencies in seinem Projekt drin und muss dann gucken, dass man eine neue Bibliothek halt findet, die das gleiche noch kann.

Und das heißt, wenn man ein Projekt fertig entwickelt hat und man guckt ein halbes Jahr später und versucht es quasi wieder zu kompilieren, dann wird das auf jeden Fall nicht funktionieren.

Nach einem halben Jahr ist es ausgeschlossen, dass es funktioniert.

Zum einen führt Google selber regelmäßig Änderungen im Framework ein, und zwar Breaking Changes.

Und zum anderen sind halt Pakete dann nicht mehr aktuell und müssen ersetzt werden, sodass quasi der Wartungsaufwand dafür nach meiner Einschätzung sehr, sehr groß ist.

Okay, das erinnert mich jetzt auch ein bisschen an die JavaScript-Developer Experience, ehrlich gesagt.

Also vielleicht hat sich das inzwischen verbessert, das weiß ich nicht genau.

Aber das waren auf jeden Fall die Probleme, mit denen ich so zu kämpfen hatte.

Okay.

Also ich habe auch gekürzt, dass Flutter irgendwie so für große Projekte irgendwann nervig wird.

Und also Capacitor habe ich da empfohlen gekriegt.

Und das geht halt auch mit View.

Ja, ist quasi dann so ähnlich wie React Native, ist halt aber für View, ne?

Ja, genau, es gab irgendwie auch mal View Native, weil das ist auch irgendwie kaputt gegangen aus derselben Gründen, weil irgendwer keine Lust mehr hatte.

Und das klingt so ein bisschen, als wäre das so der neueste Ding.

Aber ob das gut funktioniert und wie lange das funktioniert, weiß man halt auch alles nicht.

Also was mir ja ehrlich gesagt am liebsten wäre, wenn es so ausgeht, wäre halt, dass er auf allen Plattformen Web gut genug funktioniert, dass man die anderen Sachen nicht machen muss.

Aber gut.

Und mit Safari 16.4 ist er jetzt natürlich auch, also iOS hat jetzt im Hauf einen Großteil der Sachen, die gefehlt haben oder die bisher so richtig schmerzhaft waren, bekommen.

Und es sollte jetzt irgendwie dann auch quasi auf iOS halt eigentlich ganz gut funktionieren.

Aber okay, ja.

Ja, aber diese PWAs ist halt auch immer so.

Ja, ja, es hat schon alles noch so seine Act mit kann, es ist nicht ganz das gleiche, als wenn man Native das macht, ja.

Das ist schon wahr.

Kennt ihr Py-Skript?

Ja, klar.

Das ist doch eigentlich die Lösung aller unserer Probleme.

Ja, also es geht quasi darum, dass man halt Python einfach im Browser, also per WebSM wie WebAssembly im Browser laufen hat.

Ja, das große Problem an der Stelle ist halt, dass das, oder was ist halt die Frage, ob das ein großes Problem ist oder nicht, dass das halt bedeutet, dass man halt irgendwie ein paar Megabyte Zeug irgendwie runterlädt, weil der Interpreter, Python-Interpreter, der ist halt nicht im Browser drin.

Der JavaScript-Interpreter halt schon.

Und das bedeutet, man muss halt erstmal ein paar Megabyte irgendwie runterladen und kann dann erst irgendwas machen.

Wobei das ließe sich ja leicht lösen, wenn sich das so weit durchgesetzt hat, dass die Browser-Hersteller sagen, ja gut, dann wandeln wir das halt mit in den Browser rein.

Ja, das wäre natürlich eine Perspektive.

Das wäre natürlich schick.

Dann hätten wir gewonnen, aber naja.

Ja, aber dann kommen auch noch alle anderen Sauer an.

Ja, ich weiß es nicht.

Aber ja, natürlich.

Also das ist auf jeden Fall auch ein interessanter Weg, ja.

Das halt alles irgendwie dann nach WebAssembly kompiliert letztendlich.

Ich habe letztens gehört, das fand ich auch sehr interessant, dass tatsächlich, ich glaube, Figma war es.

Ich hoffe, ich erzähle jetzt nicht keinen allzu großen Ton.

Aber ich glaube, Figma ist tatsächlich eine Applikation, die ist geschrieben in C<unk> oder so.

Und dann kompiliert das aber zu WebAssembly und läuft im Browser.

Aber die Leute, die das entwickeln, entwickeln tatsächlich in C<unk>.

Ja.

Okay.

Also Figma ist das Design-Tool für alle, die es noch nicht können, mit dem man ohne Plan von Entwicklung so Screens zusammenklicken kann.

Ein bisschen mit Funktionalität versehen, um so Klickstrecken zu verwirklichen.

Wo es auch tolle Tools gibt, wo man das exportieren kann als Vue.js-Komponenten oder direkt mit CSS rausrennen kann und so weiter vom Figma.

Dann spart man sich so den Zwischenschritt.

Was sehr praktisch ist.

Was mein Problem wäre, sowas wie Qt zu verwenden, weil ich glaube, ich möchte jemanden, der von Design mehr Ahnung hat als ich, das bauen lassen, das dann exportieren und dann in meine Anwendungen importieren.

Da muss ich mich darum nämlich nicht mehr kümmern.

Ja, aber da würde ich eben denken, das ist genau diese Frage.

Du hast halt eine Bandbreite von das Design ist super wichtig und du musst hast eigentlich nicht so viel komplizierte Funktionalität, auf der einen Seite vielleicht und auf einer anderen Seite hast du halt, du hast viel komplizierte Funktionalität, aber Design ist nicht so wichtig.

Und je nachdem, wo dein Use Case ist, ist halt das ein oder andere halt interessanter, weil wenn du halt sehr viel komplizierte Funktionalität hast und dann versuch das mal einem Designer zu erklären.

Also ich würde

auch Vertriebs und aus der Marketing-Team sagen, Design ist alles.

Also ich habe immer das Gefühl, die Sachen, die super toll aussehen, aber nichts können, verkaufen sich x-mal viel besser als Ziel.

Ich glaube, das kommt auf deine Zielgruppe.

Das kommt auf deine Zielgruppe an.

Ich würde, also ja, ich würde sagen, die Normalverteilung in der Mitte sagt leider was anderes.

Also ich wäre durchaus auch bei guter Funktionalität, würde ich eher bevorzugen.

Aber naja, ich glaube, dass es selten

so ist.

Ich weiß es nicht.

Ja, ja.

Ja, aber genau, vielleicht nochmal zu dem Mia-Plan.

Das ist aber quasi entstanden für einen konkreten Anwendungsfall, in dem es dann auch eingesetzt wird, aber es verwenden jetzt auch andere Leute schon und es funktioniert eigentlich ganz gut quasi.

Und man kann das, also wenn man irgendwie so ein Problem hat mit, man möchte irgendwie Personalplanung machen, im Grunde kann jeder das einfach so dann verwenden.

Kann jeder das einfach so verwenden, genau.

Das, äh, ja, genau.

Klingt ja auf jeden Fall schon mal gut.

Ich weiß nicht, fällt dir noch was ein?

Ich überlege gerade, ob ich noch irgendwelche Fragen habe oder irgendwelche Dinge, über die man mal reden könnte, aber.

Wir haben jetzt alles so ein bisschen im Schwaben.

So wirklich tief gemacht.

Also was mir, ich höre euch ja auch regelmäßig.

Was mir aufgefallen ist, es gibt noch einen Unterschied.

Was wir anders machen, was ich anders mache als ihr wahrscheinlich.

Ihr nutzt gerne Datenbanken.

Ich nicht.

Ja, das ist auch interessant, ja.

Und Gründe, wie bitte?

Was nimmst du?

Files?

Dateibasiert, genau.

Die Gründe, warum ich, also es stimmt natürlich nicht, also ich habe auch Datenbanken, aber nur da, wo ich sie haben muss.

Also zum Beispiel, dass Jack Gamoli hat halt eine Datenbank im Hintergrund.

Da komme ich nicht drum rum.

Aber ja, Datenbanken.

Habe ich verschiedene Nachteile, die ich da sehe.

Zum Beispiel brauche ich ein Tool, mit dem ich die angucken kann muss.

Das heißt, wenn ich mal schnell was nachschauen will, dann geht das mal nicht so einfach.

Ich kann mich nicht einfach per SSH auf den Server einloggen, kann mir eine Datei anschauen mit dem Datei Editor meiner Wahl, sondern ich muss da irgendwie dann mit einem SQ-Lite, was weiß ich, Viewer oder von außen gut und gar nicht einen Port aufmachen, aber den muss ich auch erstmal aufmachen.

Dann da drauf.

Also das ist deutlich einfacher mit einer Datei, würde ich mal, würde ich mal sagen.

Dann habe ich die Wartung der Datenbank.

Ich möchte ja regelmäßig, möchte ich da, möchte ich die reinigen, ich möchte die komprimieren vielleicht.

Alte Sachen rausschmeißen.

Das habe ich auf Dateiebene zwar auch so ein bisschen, aber ich würde sagen, es ist da wesentlich einfacher.

Also wenn ich da Sachen habe, die ich nicht mehr brauche, dann kann ich die mir konkret angucken und kann dann zum Beispiel in Python dafür sorgen, dass die wieder rausfliegen.

Wie machst du das?

Also pickelst du die Sachen dann weg oder schreibst das JSON weg?

Nee, ich mache alles, was geht, mache ich menschenlesbar.

Also ja, JSON oder INI.

Also JSON mache ich auch in einigen Applikationen schreibe ich einfach tatsächlich so JSON-Files raus.

Also JSON ist ganz nett, es ist vor allem schnell.

Eigentlich würde ich gerne noch woanders hin.

Es gab jetzt ein neues Settings-Format von Python, wird nativ jetzt aufgeschnitten in drei Tommel, genau, richtig?

Message.

Das ist eigentlich das, wo ich jetzt hinwollte.

Aber ja, also sämtliche Operationen, die ich eigentlich, also ich brauche natürlich auch Operationen auf den Daten, die ich da lese, das ist klar.

Aber die mache ich eigentlich alle in NumPy.

Also ich lade die Datei in meinen Speicher rein und das geht relativ schnell.

Ich brauche nur die, also das geht mit der Geschwindigkeit, mit der ich von der Platte lesen kann.

Und kann dann halt die ganzen Aggregationsfunktionen, die ich brauche, was weiß ich, Summe, Maximum und so weiter, die habe ich in NumPy auch.

Also mache ich das in NumPy.

Ja, ansonsten Datenbank-Nachteile, ja, ich muss, ich muss natürlich, ich muss die stoppen, wenn ich ein Backup mache.

Ja, das weiß ich nicht.

Ja, okay, gibt es vielleicht so eine Live-Varianten.

Also ich kenne es noch, weiß ich nicht.

Also kommt doch an, was für eine Datenbank man verwendet, aber ich meine, jetzt bei Postgres, das geht schon.

Also da gibt es so, ja, also muss man, muss man nicht stoppen.

Aber ja, das ist natürlich ein Problem.

Ja, du musst halt irgendwie, du hast einen Fail halt, mit dem du irgendwie umgehen musst.

Von Zeugs, dass irgendwie in der Luft hängen kann, zwischen dem letzten Backup und dem, wo du gerade backuppen willst, was da an Transaktionen gerade quasi reinkommt, der relativ groß werden kann, wenn du viel Traffic drauf hast.

Ja, gut, aber also da gibt es schon Wege, damit umzugehen.

Ich meine, was da empfohlen wird, ist ja dann auch immer nicht, das selber zu machen, wenn man das nicht, weil das natürlich ein Riesenaufwand ist, sich da einzuarbeiten.

Das ist durchaus ein Nachteil, ganz klar.

Man kann ja auch da Dienstleister benutzen und sowas wie Quruntry Bridge, Crunchy Data verwenden oder so oder sonst irgendwen, der halt sowas Manage Postgres anbietet oder so.

Okay, interessant.

Dann muss ich übernehmen, dass wir an die Shownotes packen.

Bitte?

Packe ich bitte nochmal in die Shownotes.

Ja.

Aber man kann das auch selber machen, was sie tun.

Hat aber den Nachteil, dass dann meine Daten woanders liegen.

Ja, ja, gut, okay.

Und das will ich eigentlich nicht, sondern also was mein Ansatz ist, ich möchte eigentlich gar keine Kundendaten haben.

Und wenn ich sie haben muss, dann möchte ich so wenig wie möglich davon haben.

Also deswegen zum Beispiel bei der Anmeldung verlange ich auch nur Nutzername und Passwort mehr nicht.

Noch nicht mal eine E-Mail.

Ja.

Das heißt,

wenn jemand sein Passwort vergisst, ist halt.

Dann kann er mich anschreiben.

Dann kann er mich anschreiben und falls das öfter passiert, es ist tatsächlich noch nie passiert, dann mache ich das in automatischen Verfahren draus.

Aber solange das nicht häufig vorkommt, ich antworte auch schnell.

Ja, ja,

nee, ich denke auch, dass es halt wieder eine Frage, wer die Kunden sind.

Also wenn du jetzt ganz viele Endkunden hast, an denen du nicht viel verdienst und alle Kunden automatisiert sein, ist es schlecht, wenn die Leute alle dich anschreiben, genau.

Wenn du jetzt nur

das Open hast,

die sich auskennen, dann ist das halt alles nicht so schlimm.

Ich werde das auch automatisieren, solange das überhand nimmt.

Wenn das überhand nimmt, aber das ist nicht der Fall.

Datenspartei, ich finde es interessant.

Ich weiß nicht.

Ich denke mir so, ah, irgendwas könnte man mit den Daten auch anfangen.

So ausher.

Also jetzt ohne der Sonne.

Es gibt ja auch die Verantwortung an die Hand.

Also wenn ich jetzt sage, ich habe hier einen Riesenhaufen von Nutzerdaten mit E-Mail-Adresse, Passwörtern, Bankdaten, was weiß ich, und dann kommt irgendjemand auf meinen Server und trägt das ganze Zeug raus, dann habe ich auf jeden Fall ein Problem.

Und das kann ich schon mal insofern vermeiden, wenn ich das Zeug gar nicht erst habe.

Das würde zum Beispiel für, aber auch für Managed sprechen, weil dann hast du die Verantwortung quasi auch abgegeben.

Naja, du schließt dann einen Service-Vertrag mit dem, der das halt managt.

Aber in der Verantwortung stehe trotzdem ich.

Also ganz so ist das für mich.

Ja, also wenn jemand dann, also nehmen wir an, du hast eine Managed-Datenbank irgendwo gekauft, zum Beispiel bei Quanchi Data und dann irgendwie Quanchi Data, da geht irgendjemand rein und trägt alle Daten raus, dann hast du natürlich trotzdem ein Problem.

Auch wenn du das vertraglich dann sagen kannst, das bin ich gar nicht jetzt, ich bin jetzt vielleicht aus der Haftung oder aber das ist ja trotzdem Kacke für deine Kunden und überhaupt nicht.

Ja, aber es kommt halt genau auf da, vielleicht auf die detaillierte Vertragsbeziehung mit deinen Kunden oder mit den Kunden deiner Kunden an und so.

Ja, aber vielleicht willst du das auch einfach gar nicht.

Vielleicht sagst du, ich will das nicht mehr.

Aber die Frage ist halt tatsächlich, also was jetzt aus der auch jetzt aus so einer Datenraustrageperspektive sicherer oder besser ist, wenn man jetzt ein kleines Team hat, sich noch komplett um so ein Datenbank-Cluster-Management zu kümmern zu müssen.

Oder dass halt ein Service-Dienstleister auszusourcen, der da vielleicht mehr Zeit für hat oder mehr Ressourcen, weil er das nur macht und da sich auch besser damit auskennt, als man selber.

Und das geht ja für verschiedene andere Services

auch so.

Also es kann durchaus sein, dass das sogar die sichere Alternative ist.

Würde ich auch sagen.

Wenn du das outsourced, wenn du dich selber halt nicht damit auskennst.

Genau.

Oder man hat halt nicht so relevante Sachen.

Und ich sag mal so, ja, okay, klar, gibt es so Punkte, wo man jetzt gucken muss, dass man jetzt nicht alles so sammelt wie jetzt die letzte Krake.

Da gibt es ja so ein paar Google-Kraken, die das so machen.

Ja, aber es gibt viele Unternehmen, die erstmal alles in ihrem Data-Lake irgendwo hin.

Ja, also ich würde jetzt auch nicht alles machen.

Vielleicht kann man damit irgendwann mal irgendwas anfangen, aber da bin ich auch kein Freund von solchen.

Also ich kann das so ein bisschen verstehen.

Also jetzt nicht von Kunden, aber wenn ich jetzt so eine Request habe oder so, warum soll ich die ganzen Informationen da wegschmeißen?

Also der neueste Trend scheint zu sein, dass jeder Dienst, egal wie unwichtig der ist, meine Telefonnummer haben will.

Und das finde ich ganz grausam.

Ja.

Also ich würde jetzt auch sagen, also ich will ja, mir geht es gar nicht so um Kundendaten, sondern eher so um so einen Meta-Quatsch.

Logzeitstempel oder sowas.

So Telemetrie.

Weil das in Sinn.

Und ohne, dass ich jetzt irgendwie so ein Nutzer daran identifizieren möchte, um irgendwie da noch ein Quäntchen Umsatz rauszuquetschen, sondern einfach nur so ein bisschen um den Flow so ein bisschen besser im Blick zu haben.

Ja, technische Daten brauchst du natürlich.

Das steht ja außer Frage.

Sonst funktioniert die Software ja nicht.

Ja.

Ja, aber auch da, ich meine, man macht sich vielleicht nicht immer klar, welche Optionen man eigentlich hat.

Natürlich kann man irgendwie Sachen speichern und so.

Also die Frage ist halt, wiederum, wenn du nicht so viele Nutzer hast, du kannst ja auch einfach fragen.

Also wäre jetzt auch so ein GraphQuery-API, ne?

Wenn ich jetzt nicht ein Problem mit Latenz habe, ich ziehe mir dann ein Maximum und schmeiße alles weg, was ich nicht brauche.

Also man könnte natürlich auch direkt die Query so effektivieren.

Es gibt auch Leute, die

so an der Dominik.

Du kannst auch direkt die Datenbank quasi in deinen Browser reinpacken.

Das geht natürlich auch.

Es gibt auch bestimmte Anwendungsfälle, in denen das sinnvoll ist.

Aber ja, es gibt gute Gründe, warum Leute das anders machen.

Also Vorteil.

Weitere Vorteil ist, wenn ich die Daten nicht sammle, dann habe ich auch Backup deutlich kleiner.

Also ich würde, einer der wichtigsten Argumente ist vielleicht auch, dass es weniger Strom verbraucht, so ein bisschen weniger Kosten, auch ökologisch oder so.

Aber ich finde das, also so das Ding als Grundsatz zu sagen, schaue mal, ob ich jetzt nicht vielleicht irgendwie, welche Daten ich wirklich brauche und welche halt nicht.

Und die, die ich nicht brauche, die speichere ich gar nicht erst.

Das finde ich eigentlich schon recht sinnvoll.

Ja, tatsächlich als

eigentlich für so ein ORM-Ding sprich mal mit klaren definierten Modellen, mit einer klaren Validierung.

Na, ich weiß, also zu dieser grundsätzlichen Frage Datenbank ja oder nein, aus meiner Perspektive ist das jetzt eher, würde ich ja sagen, ja, gut, das Dateisystem ist ja auch eine Datenbank.

Es ist halt nur eine andere Art von Datenbank.

Es ist halt eine hierarchische Datenbank und keine relationale.

Busckt ja auch ein Fall irgendwo rum.

Ja, genau.

Insofern ist halt auch da die Frage, und es ist ja auch, wenn man eine Web-Anwendung hat, die sind die, die auch eine, jetzt wenn man ein Django hat oder so, oder was auch immer, für eine Standard-Web-Anwendung, dann üblicherweise hat man ja auch da nicht nur Daten in Tabellen, sondern da hat man ja auch noch was anderes.

Da hat inzwischen eigentlich nicht mehr wirklich Fallsystem.

Früher war es dann ein Fallsystem noch, aber inzwischen ist es halt ein Object-Store meistens.

Ja, irgendwas Cash-Redis oder.

Cash gut, aber das ist jetzt nicht unbedingt Teil der Datenhaltung.

Da liegt ja auch nur eine Kopie von dem, was man sagt.

Du musst ja zum Beispiel redest jetzt auch nicht nur aus Cache nehmen, du kannst halt auch da irgendwie bestimmte Sachen Vorbrechende ablegen, wenn das irgendwie.

Das ist nochmal eine andere, da würde ich sagen, Redis ist halt so ein Key-Value-Store irgendwie im weitesten Sinne.

Aber dafür gibt es natürlich auch wieder Annonsfälle, wo das gut ist.

Aber also diese Kombination relationale Datenbank auf der einen Seite, auf der anderen Seite Object-Storage für halt irgendwie Daten, die jetzt irgendwie eine interne Struktur vielleicht haben, aber die jetzt nicht irgendwie, das ist eigentlich schon eine super Kombination.

Aber ja, ich meine, gut, Fallsystem hat natürlich auch Vorteile.

Was würdest du damit mit den Object Store nehmen?

Ja, also das habe ich leider nochmal, was ich mir gerne angucken würde und wovon ich jetzt schon Gutes gehört habe, im Zuge von Mastodon hat ja dieses Problem auch.

Also Leute wollen ihren eigenen Instanzen hosten und haben dann jetzt auch das Problem, dass da ganz viele Bilder und Videos und so Zocks kommen, dass die sie irgendwo hinlegen müssen.

Und wenn man das halt nach, ich habe jetzt letztens irgendwie wann war das?

Es gestern Morgen oder so, keine Ahnung, war auch Python-Podcast war weg.

Hä, warum das denn?

Naja, gut, Platte vollgelaufen.

Und warum?

Ja, weil da eine Mastodon eine Instanz auf dem gleichen Rechner läuft, die halt irgendwie alles vollgemüllt hat.

Und genau, dann die Standardlösung oder das erste ist dann halt, Leute legen das dann nach S3 oder so und stellen dann fest, oh mein Gott, das ist ja voll teuer.

Ja, das ist.

Und ja, ich habe jetzt, ich weiß nicht, vor den letzten Monaten und ich habe ja eine super kleine Instanz.

Ich habe trotzdem die letzten drei, vier Monate hat das Ding irgendwie 60 Gigabyte Daten oder so angesammelt an Zeugs.

Und gut, bei größeren Instanzen wird das noch viel, viel mehr sein und dann wird das halt irgendwann teuer, wenn man das halt alles nach S3 legt.

Und dann ist die Frage, okay, kann man das irgendwie selber machen?

Ja, kann man.

Was ich dafür schon verwendet habe, ist so Mini-IO.

Ja, das aber so.

Das Problem dabei ist, ja, also einmal macht das.

Das ist quasi.

So ein Bugnet-Lokal.

Gleicher AP, gleiches Interface wie S3.

Gleicher API wie S3, aber du kannst halt selber husten.

Das ist eigentlich ganz nett, ja.

Also so prinzipiell die Idee.

Ich glaube auch GPL.

Ja, das kann, das kann man durchaus verwenden.

Auch im kommerziellen Kontext geht das.

Aber es gibt da eine Firma hinter, irgendwie, die sitzt auch im Silicon Valley, das ist alles irgendwie ein Go-geschrieben und da arbeiten viele Leute, die haben wirklich viel, viel Venture-Capital eingesammelt und so.

Das müssen sie halt irgendwie auch wieder rausholen.

Das heißt, irgendwann werden sie irgendwie versuchen, Methoden zu finden, wie sie einem dafür irgendwie einen dafür bezahlen lassen können, was ja auch irgendwie legitim ist, aber das ist halt so ein bisschen.

Und was halt der große Nachteil von Minio ist, dass du da nicht dynamisch irgendwie Dinge hinzustellen und wegnehmen kannst, sondern das ist halt schon eher so auf den Betrieb ausgelegt, du weißt schon, wie viel Platz du hast und das ist alles fertig.

Wieso kannst du nicht dynamisch was.

Du kannst halt nicht einfach eine Maschine dazustellen und sagen, so hier eine Maschine mehr.

Du kannst auch so ein Cluster, dann kannst du irgendwie die in so eine Liste eintragen und dann.

Das ist dann etwas, wo dann die Leute draufgestoßen sind, die dann Vinio verwendet haben.

Das ist ja der große Vorteil von AWS und Lambda-Geschichte, dass du das halt einfach hochskalieren kannst mit dem Klick.

Ja, genau, also wenn du, aber Vinio ist eher so für jemanden, der sowas wie S3 betreiben möchte und dann halt schon, ja, wo du dann halt schon einen Datasenter hast und wo das alles, aber wenn du jetzt dynamisch irgendwie so sagst, oh, ich brauche jetzt aber nochmal ein paar Terabyte mehr Daten, Speicher, dann ist ein Minü.

Das kannst du deinem Menü-Cluster kannst du Sachen auf jeden Fall hinzufügen.

Das heißt, wenn du dir irgendwie dynamisch Kisten spawnst, auf denen du Minü aufsetzt und die dann kannst du einfach deinem Cluster hinzufügen.

Also theoretisch geht das halt schon.

Ja, also jedenfalls, also ich habe, ich beziehe mich da jetzt auf die ganzen Performance-Tuning und so Dinge, Artikel, die Leuten dann aufgefallen sind, die große Master-Instanzen mit haben, die meinen so, ah shit, das geht nicht mit Minute geht nicht gut, weil du kannst es nicht dynamisch.

Kannst du Sachen hinzufügen oder wegnehmen, geht nicht gut.

Und die sind dann alle umgestiegen auf etwas, nennt sich CWEDFS.

Okay.

Und da geht das wohl.

Das habe ich aber selber noch nicht ausprobiert, also keine Ahnung.

Sea.

Ja.

Ja.

Genau, das sind halt so die Dinge, die man.

Wieder auf die Ansible-To-Do-Liste.

Ja.

Naja, genau.

Aber ja, also die Kombination ist eigentlich schon gut, aber ja klar, ich sehe auch, dass man, wenn man ein Fallsystem hat, ist auch nicht so schlecht, ja.

Also wenn man da tatsächlich reingucken kann und so.

Ja.

Ja, ist halt immer kommt auf einen Anwendungsfall an, was jetzt da mehr Sinn macht.

Ja, aber ich meine, sozusagen aus der Datenbankenperspektive, du musst dich ja jetzt dann auch tatsächlich um solche Sachen kümmern wie Backup und was passiert eigentlich, wenn irgendwas weg ist, wie kommt das wieder zurück?

Und diese ganzen Prozesse, wo du ja, ich meine, klar, bei Datenbanken ist es halt vielleicht komplizierter, aber da gibt es ja schon eine fertige Lösung für, das musst du dann ja selber bauen.

Eigentlich.

Naja, eigentlich nicht.

Also wie kommt das zurück, war ja deine Frage.

Naja, mit Einsible und dem Backup.

Ja.

Und ja, Backups mache ich mit Borg.

Hab noch nichts Besseres gefunden.

Restic ist gut.

Kennst du Resticke?

Resticke.

Habe ich gelesen, brauche ich da aber eigentlich nicht.

Also hab noch keinen Anwendungsfall, wo ich jetzt oberhalb von Borg noch was brauchen würde.

Was kann Restic noch zusätzlich?

Du kannst halt auch direkt auf einen Bucket Backup zum Beispiel oder so.

Ach so.

Oder auch irgendwo, wo halt einer läuft, also relativ gut ist.

Ja, das mache ich sowieso.

Aber gut, das mache ich dann händisch.

Also nicht händisch, sondern automatisch, also ich habe es programmiert, sodass es jetzt automatisch läuft, sozusagen.

Ja.

Ja, aber ja, also die, ich meine, klar, das ist schon eine berechtigte, also muss man sich eigentlich schon überlegen, es ist ja meistens so, dass relationale Datenbanken immer so gesetzt sind.

Aber ob das für alle Anwendungsfälle immer so der Default sein sollte, weiß ich auch nicht.

Das ist schon, kann man auch nochmal drüber nachdenken.

Ob das für den eigenen Fall irgendwie Sinn macht.

Ja.

Ich meine, aus so einer Software-Architekturperspektive kann man natürlich auch einfach sagen, das ist halt ein Implementationsdetail, das ich jetzt aus dem Kern meiner Software auch eigentlich raushalten kann.

Ich mache in dem halt irgendwie Repository-Puttern oder so und dann habe ich sowieso in meiner Applikation oder in meiner Kernlogik irgendwie nur mit Objekten zu tun und wie die jetzt letztlich gespeichert werden, ob die in einem Fallsystem landen, in JSON oder Toml oder der Datenbank, das da ist letztlich egal, da kümmert sich irgendwie ein anderer Teil drum und das ist gar nicht im Kern meiner Applikation drin.

Naja, der Vorteil der Datenbank, das sehe ich in erster Linie in den Aggregationsfunktionen, die das halt mitbringt.

Ja.

Aber das mache ich halt woanders dann.

Ja, ja, du, also ich meine, du könntest halt, also ich meine, was du in NumPy halt nicht hast, wenn jetzt so große Datenmengen hast, dass die gar nicht so wirklich in deinen Hauptspeicher passen.

Wenn die nicht in den Speicher passen, richtig.

Aber auch da gibt es Lösungen tatsächlich.

Da gibt es Abstraktionen von NumPy, die das quasi so chunk-mäßig dann bearbeiten.

Also das geht tatsächlich auch.

Ach, cool, wenn man das will.

Ja, oder überhaupt so Indizes und so hast du wahrscheinlich dann eher nicht.

Nee, brauche ich nicht.

Außer nicht.

Man können auch keine Indizes kollidieren, wenn ich zwei dicke Datensätze zusammenfüge.

Ja, insofern, also auf jeden Fall finde ich sehr interessant, weil viele irgendwie eher unkonventionelle Ansätze oder so, aber ja, auf jeden Fall sehr interessant.

Und für den Anwendungs, also für den Anwendungsfall macht das wahrscheinlich durchaus alles Sinn.

Hat natürlich alles Vor- und Nachteile, aber gut, da muss man sich halt dann informieren vorher.

Ja, ich weiß nicht, hast du noch irgendein Thema Martin, was ist, was du, wo wir jetzt noch nicht drüber gesprochen hätten?

Oder sind wir quasi durch?

Nö, aktuell, würde ich sagen, haben wir relativ breit alles erschlagen.

Da machen wir noch Picks.

Gut.

Wer möchte anfangen?

Okay, dann fange ich mal an.

Moment.

Picks.

Ich würde gerne eine auch eine kleine, feine Anwendung picken.

Die jetzt ist auch wieder natürlich nicht für so wahnsinnig viele Leute interessant ist, gibt es auf iOS und auf dem Mac.

Und zwar heißt die Paprika.

Und das ist so eine Rezeptverwaltung.

Ich weiß nicht, wenn man halt irgendwie gerne kocht und viele Rezepte hat und so, dann überlegt man sich ja häufig, wo man die dann irgendwie zentral lagert oder keine Ahnung, was man damit.

Obsidian.

Ja, Obsidian.

Ja, gut, aber das ist dann halt, das ist halt sehr puristisch irgendwie.

Du kannst ja auf direkt Static-Pages, das für Rezepte eigentlich sich dafür sehr gut erinnern lassen, deinen Bock.

Ja, aber klar, kann man machen, ist halt aber nicht unbedingt auf den Rezeptanwendungsfall irgendwie so wahnsinnig gut zugeschnitten.

Und das Ding kann halt so Sachen wie zum Beispiel man, das hat einen eingebauten Browser und dann, wenn man irgendwo im Web ist und sieht halt irgendwo ein Rezept oder so, dann kann man sagen, okay, speichere mir das mal.

Und dann kann man halt die unterschiedlichen Teile, also man hat sozusagen ein Schema, in dem die Rezepte irgendwie gespeichert werden.

Und dann kann man halt in dem eingebauten Browser kann man dann halt so Rechtecke ziehen und sagen, so, das hier sind die Zutaten und dann zieht man da einfach ein Rechteck drüber und sagt, so da waren die Zutaten und dann macht es halt flup und dann sind die Zutaten halt in einem ordentlichen Format drin.

Oder hier, das ist das Bild, wo man wirklich sehen kann, was da drauf, also will, weil woher soll, will man sonst wissen, oft auf Webseiten gibt es halt viele Bilder, wo ist denn, welches Bild ist denn hier zum Lass, auf dem das wirklich zu sehen ist, was da gekocht wurde?

Und dann klickt man halt auf das Richtige und dann hat man hinterher, also mit relativ wenig, also hat sich jemand wirklich Mühe gegeben, dass man mit relativ wenig Aufwand und irgendwie auf so eine Seite rumklicken quasi ein Rezept in eine sehr strukturierte Form bringen kann, wo man dann nachher so Abfragen machen kann wie, gib mir doch mal alles, wo irgendwie Zucchini vorkommt und irgendwie, keine Ahnung, weiß ich nicht, und ein Dessert ist oder so und das funktioniert dann.

Was mit dem Obsidianansatz natürlich ist dann halt schwieriger.

Ja, genau.

Und das synchronisiert halt auch, man kann auch direkt sagen, wenn man ein Rezept hat, okay, mach mir mal eine Einkaufsliste draus und so und ja, dann hat das dann halt auf dem Telefon bzw.

auf der Uhr, wenn man durch den Supermarkt läuft, dann kann er die Sachen wegklicken.

Also sehr, sehr angenehmes Ding.

Ich bin Ben Nesswing drauf gekommen, weil ich habe ja halt so eine so eine Webseite Captain Cook irgendwie.

Da gibt es immer ganz interessante Vorschläge, was Rezepte angeht, so drei pro Tag.

Und ich hatte früher auch eine Kombination aus Python Backend und Vue.js Melee verwendet.

Früher, also vor drei Wochen.

Vor einem Jahr ungefähr, habe ich damit mal angefangen.

Weil das auch ganz interessant aussah.

Aber ehrlich gesagt, also das zu deployen ist schon ganz schöner Horror.

Ja, ich habe Melee nicht so cool.

Ja.

Aber und dann habe ich irgendwie ein Ding gebaut, was mir sozusagen die Rezeptgeschichten, die es da bei dieser App gibt, in dieser Captain Cook-App, halt rübersynkt in meinen Melee und ich dann halt nur noch Millie verwenden muss und nicht mehr die komische App, weil die App von Captain Cook ist halt, sieht zwar irgendwie nett aus, aber sie ist halt funktioniert nicht so richtig.

Und genau, und da hat jemand dann einen Pull-Request gegengestellt und hat gesagt, hier soll das nicht auch vielleicht mal nach Paprika sünken und so.

Ich dachte so, Paprika kann ich gar nicht.

Ja, bin ich auch aufmerksam geworden und ja, voll super, jetzt übt das halt auch dahin.

Und jetzt verwende ich Paprika.

Und es bin sehr zufrieden.

Also ja, also was echt cool klingt, ist halt mit den Bildern in den Zutaten, weil ja, ich mache das halt immer alles selber, aber gut, ja.

Koratierte Rezepte, ja.

Okay.

Cool.

Ich würde Copilot Labs picken.

Ah.

Also Copilot haben wir ja schon ein paar Mal drüber gesprochen.

Wunderschöne Extension für den Editor deiner Wahl zum Bessermachen.

Copilot Labs ist, ich weiß nicht, ob es auch für andere IDs geht als VS Code, aber damit kannst du halt so Sachen machen wie, äh, marquiert irgendwie ein paar Funktionen, mach doch mal bitte Type ins dran oder ein paar Tests hätte ich hier gerne und so.

Und das funktioniert ganz gut.

Das ist ganz nett.

Oder übersetzt das mal in eine andere Sprache.

Also hier habe ich einen Python-Code, hier gern Go oder andersrum oder ja, das.

Okay, hab ich auch noch nicht.

Ich verwende immer nur eine Standard-Copilot, äh, ja.

Ja, und das würde ich sagen, das ist eine sehr, sehr geile Extension noch dazu.

Was ich beim Copilot gelesen habe, ist das folgende, wenn da ein Fehler auftritt, also angenommen, man nutzt halt Copilot in VS Code oder so, dann schickt er einmal komplett alle geöffneten Files zu Microsoft rüber.

Und da bin ich ein bisschen schützig geworden, ob das denn so geht.

Und Teams-Chat und so und alles, was so im Memory hängt, noch irgendwie an.

Ja, das weiß ich nicht, aber also ich habe halt gelesen, alle geöffneten Files im VS-Code schickt er dann rüber.

Und das geht ja dann nicht.

Also wenn er zum Beispiel irgendeine Firma sitzt, glaube ich kaum, dass die Company-Richtlinien das dann erlauben.

Ja, ich meine.

Depends.

Ja, ja, genau.

Das ist natürlich schon ein Problem.

Es gibt ja so den berühmten Spruch, da würde ich jetzt sagen an der Stelle, better ask for forgiveness than for permission.

Ja.

Es kommt ja vielleicht darauf an, ob du jetzt tatsächlich patentrelevante Dinge machst oder nicht.

Sagen wir es

mal so.

Na, also ich meine, auch da auch OpenAI hat da ja diverse Probleme, die sind ja irgendwie, wie heißt das, Italien, die Teilen ist komplett gesperrt worden.

Ja.

Jetzt ist es wieder frei, ja.

Jetzt ist es wieder frei, aber weil sie da haben da, aber das fand ich schon auch ein bisschen dreist von OpenAI, dass sie da halt wirklich gar nichts zu sagen.

Ich meine, sie können ja da, man kann ja, wenn man das sagt, was man da tut mit den Daten, so kann man ja durchaus einiges machen, aber sie haben halt einfach gar nichts dazu gesagt.

Und das ist halt schon.

Wobei das ist ein bisschen andersrum.

Man konnte die Story gar nicht verstehen, Entschuldigung.

Welche Story?

Du hast sie da einfach gesperrt haben, Italien.

Ich dachte, Italien hat sich überlegt, dass sie keinen Bock drauf haben.

Nee, nee, nee, nee.

Das hat eine europäische Geschichte.

Das hätte auch dann, das droht da auch dann in anderen europäischen Ländern passieren, weil du musst halt, wenn du irgendwie Daten von Leuten speicherst oder damit irgendwas machst, musst du halt zumindest sagen, was du da tust und warum.

Und das haben sie nicht gemacht.

Und daher kann man sagen, okay, darfst du deine Produkte in der EU nicht anbieten und Italien hat das so ausgelegt, das kann jedes Land dann so auslegen, wie sie das möchten, dass da jemand mehr drauf zugreifen kann.

Ja, gut, aber Artikel 61F DSGVO zum Beispiel sagt, dass ein Anbieter eines Dienstes alle für den Vertragserfüllung relevanten Daten durchaus erheben darf.

Ja, ja, ja, klar, aber du musst du musst trotzdem sagen, was du da irgendwie machst und warum.

Du darfst das schon, aber sie haben ja nicht mal was dazu gesagt.

Und das machen sie jetzt und dann geht's wieder.

Also insofern.

Aber ja, ich meine, na, so.

Nee, ist hab ich.

Wobei da ist so ein bisschen andersrum.

Also da nimmt sich ja OpenII quasi den Datensatz Internet und lernt da drauf.

Und falls sie damit was machen, was sie nicht dürfen, haben die ja das Problem.

Bei Copelot ist es ja so ein bisschen andersrum.

Da ist ja der Anwender quasi dafür verantwortlich.

Also wenn der Anwender in der Firma sitzt und lädt jetzt Teile des Quellcodes der Firma irgendwo hoch, darf, glaube ich, der geneigte Mitarbeiter eigentlich auch nicht.

Nee, ist aber so, wenn du bei GitHub bist, ist es eh wurscht, ne?

Ja, wenn dein Code da E liegt, ja, klar.

Aber ich meine, das ist auch was, was Leute halt so bei ChatGPT oder so reinpessen.

Also ehrlich gesagt, ich pesse da ja auch viel Code rein.

Also daher das ist halt auch ein Anwendungsfall.

Und da ist wahrscheinlich auch viel Solx dabei, wo man als Firma ein Problem mit hatte, wenn Leute das halt machen.

Aber ja.

Ja, aber als Firma, ey, ganz ehrlich, gerade als Firma ist doch wohl ein berechtigtes Interesse daran, Produktivität, Effektivität zu haben und die ganzen Secrets, die irgendjemand damit preisgeben könnte, die Maschine dahinter, die fängt jetzt ja nicht an, individuell nach dir zu suchen und deine Secrets rauszupaldovern, um da selber ein Profit zu machen.

Also gerade aus, also auch als Firma würde ich das machen.

Aber viele könnte Solte dabei.

Ja, aber

ich weiß jetzt nicht, ob ich meine wirklich jetzt meine patentierbaren Sachen da irgendwie zu mir lassen würde, aber ansonsten würde ich jetzt sagen, hm, und es gibt halt auch zum Beispiel, wenn man das nicht möchte, als Firma ja durchaus Auftragsdatenverarbeitungsdinge, wenn man jetzt mit dem Microsoft Professional Vertrieb spricht, wo man dann APIs bekommt, wo die Daten halt nicht zurückgeflossen werden sollen und so weiter.

Das heißt, dann meint man halt sowas, dann hat man halt einen anderen API-Endpunkt mit einem anderen Api-Key, basta.

Ja, genau.

Also ich weiß von einer Firma, da ist in den Firmenrichtlinien Copilot direkt verboten worden.

Ja, das stellen sich auch immer alle ziemlich viel an.

Also ich fand den Punkt auch von, ich weiß gar nicht, wer das gesagt hatte.

Ich glaube, Manwald hat das auch in der letzten Episode gesagt, bei Firmen ist ja sowieso ab einer gewissen Größe, so effizient kannst du da gar nicht mehr sein.

Jeder Angst hat dann, dass du jedes einzelnes Softwarepaket irgendwie verifizieren musst von irgendeinem Audit-Team, was meinst, kann es besser als die Open-Source-Community und so.

Und dann sitzen da zwei Männchen und machen dann ein Audit von 150.000 Davis-Paketen oder sowas.

Entschuldigung.

Muss ja nicht alles sinnvoll sein, aber das

worüber reden wir?

Ist das eine ABM oder was?

Also ganz ehrlich, die Kosten und den Nutzen vom Business würde ich jetzt sagen, auch von, tu jetzt mal so, von einem anderen Flight-Level würde ich sagen, ist das vernachlässigbar.

Naja, muss halt die Firma dann am Ende entscheiden.

Und das kommt

halt dann eher nicht der Mitarbeiter.

Ja, genau.

Aber das ist die Frage, ob sich jemand in der Firma damit auskennt, um diese Entscheidungsgrundtage zu haben, das

zu verstehen.

Oft genug wahrscheinlich nicht, aber

ja, das ist halt ein Trade-off.

Ja, genau.

Ja.

Ja, okay, aber Copilot Labs, okay, interessant.

Ja, jetzt haben wir, du hast noch einen Pick auch, Martin.

Ja, ihr hattet ja eine Episode mal gemacht zu PyPy.

Ziemlich cooles Tool übrigens.

Und ich habe noch so eine Ergänzung dazu quasi.

Das nennt sich Number.

Ah ja, okay.

Und das ist von den Entwicklern von Anaconda.

Anaconda, das ist die quasi Python-Distribution.

Und das finde ich auch richtig genial.

Mein großer Wunsch war, ich schreibe oder mein großer Traum war, ich schreibe Python-Code.

Dann drücke ich einen Knopf und der übersetzt mir das nach C.

Und im Prinzip macht es das eigentlich fast ohne Code-Anpassung.

Also alles, was ich da machen muss, ist, ich mache einen Decorator über meine Funktion drüber und muss ein bisschen aufpassen mit den Eingaben, also über die Funktion drüber, muss ein bisschen aufpassen mit den Eingabe und Ausgabedatentypen.

Und dann ist es das.

Aber erzeugt er mir quasi zur Laufzeit C-Code, cache die und führt die quasi mit C-Geschwindigkeit aus, die Funktion.

Finde ich ab, habe ich probiert, funktioniert genial.

Ja, wo würdest du, hast du auch schon mal Seiten ausprobiert?

Weil das ist mal so, das, was so standardmäßig irgendwie auch bei CycitLearn oder so verwendet wird.

Das Problem ist, wenn das Projekt hinreichend groß wird, dann habe ich, also ich habe ja bei Seiten und bei PyPy nicht so richtig die Wahl, dass ich jetzt nur einen bestimmten Teil meines Projektes damit habe.

Doch, doch,

also Zeiten auf jeden Fall.

Also oder ich weiß nicht.

Zeiten ist einfach auch eine Art Python-Dialekt, wo man aber dann zum Beispiel, wenn man es schneller haben will, die Typen mit dazu schreibt, ist halt ein bisschen auch älter als C2-Annotation, deswegen.

Ja, ja,

ich erinnere mich, aber da musst du einiges für tun.

Also da musst du eigentlich den ganzen Code umstellen.

Nee, nee, nee, nee.

Das kannst du für einzelne Funktionen auch machen.

Ja, ja, aber wenn die Funktion schon da ist, musst du sie umstellen.

Ja, das ist richtig.

Stimmt.

Und das musst du bei einer Nummer nicht unbedingt.

Okay, ja.

Und bei Nummer brauchst du das nicht, da kannst du das lassen.

Eigentlich wie es ist.

Klammer auf, abgesehen von den Eingabe- und Ausgabedatentypen, die müssen ein spezielles Format haben, aber da ist eigentlich, also wenn du eine NumPy-Matrix zum Beispiel hast, die kannst du mehr oder weniger so lassen.

Und dann ist es das.

Dekorator drüber, Funktionen sind C, fertig.

Und ich kann sie von Python aus genauso rufen wie vorher.

Und die ist halt einfach tausendmal schneller.

Ja.

Ja, ja, ja, ja.

Nee, Nummer ist auch super, ja.

Ja.

Cool.

Da wir jetzt halt bei den Speed waren, hat es eben auch noch erwähnt, das wollte ich jetzt nochmal an ins Ende packen, Polar IRS.

Ich glaube, das ist auch cool.

In dem Zusammenhang, wenn wir schon bei Speed wieder sind.

So als DataFrame-Tool für Rust und Python irgendwie noch kombiniert.

Oh ja.

Ja.

Genau.

Ja, vielleicht, ja, ich höre immer, Python ist langsam.

Ja.

Also bis jetzt lag es immer an mir und nicht an Python.

Ja.

Und wenn es an mir lag, dann hatte ich auch eine Chance, das zu beheben.

Also da gibt es zum Beispiel den Line-Profiler für Python.

Weiß nicht, ob ihr das kennt.

Ist das der Eingebaute, ne?

Nee, ist nicht der Eingebaute.

Also Line-Profiler macht im Prinzip folgendes: Du ist auch wieder ein Dekorator, den schreibst du über deine Funktion drüber und der annotiert dir an jede Quellcodezeile, wie schnell oder langsam die war.

Ah, okay.

Und dann kannst du quasi, also dann, also üblicherweise würde man das so verwenden, du findest erstmal die Funktion, die langsam ist.

Das kannst du mit den klassischen Tools machen.

Ja, also was man halt üblicherweise so nimmt, da springen ja hinten quasi die Funktionen raus, die langsam sind, wenn man es richtig bedient.

Und dann gehst du quasi mit dem Line-Profiler in die Funktion rein und schaust dir an, was genau ist denn da langsam.

Und so kommt man echt richtig schnell zu einer Performance-Analyse.

Kann das dann beheben oder dann irgendwie auch doch ein C oder miteinander Decorator versehen und so.

Hast du irgendeinen Lieblingsprofiler so für die globale Sicht?

Ich habe in letzter Zeit häufiger mal Skalinen verwendet, aber.

Nö, da nehme ich den Python-Standard.

C-Profile, ja.

C-Profile.

Genau.

Funktioniert, ist nicht schön, bedienbar, aber auch funktioniert.

Ja, funktioniert.

So oft braucht man es ja auch zum Glück auch nicht.

Also ich bin auch kein Freund von Pre-Major Optimization.

Also ich optimiere dann, wenn ich wirklich feststelle, es ist langsam.

Und für meinen Geschmack ist Python oft nicht langsam.

Aber wenn es eben doch mal langsam ist, dann muss man mich an zu profilen und dann kriege ich das.

Bis jetzt habe ich es immer weggekriegt, das Problem.

Ja, ne, klingt gut.

Ich habe das verlinke ich vielleicht auch nochmal.

Letztens einen ganz interessanten Artikel gelesen zum Thema Mythen, der von Performancem, und das ist halt ein, jetzt habe ich den Namen nicht parat, ein Spieleentwickler, der da halt auch schon langer, seit langer Zeit hat, der hat auch so einen YouTube-Channel, der irgendwie relativ beliebt ist.

Und der hat dann so einen Artikel geschrieben, wo er irgendwie so darüber rantet, was halt aus seiner Sicht die Leute immer sagen über Performance, was alles nicht stimmt.

Und da waren so, sind so ein paar interessante Sachen dabei, wo ich dachte, oh, das höre ich sehr oft, solche Sachen und das wahrscheinlich Quatsch.

Also wo er zum Beispiel sowas schreibt wie, naja, die Leute sagen immer, man muss eigentlich nur die Hotspots irgendwie optimieren.

Also du machst halt erstmal keine Performance-Geschichten, entwickelst ohne Performance im Hinterkopf zu haben, irgendwie eben keine Premature Optimization dein Code.

Und dann, wenn es langsam ist, dann guckst du halt, wo es langsam ist und dann optimierst du das weg und dann meint er so, ja, also das funktioniert ja auch manchmal, aber manchmal halt auch nicht.

Und gerade wenn du jetzt wirklich performance-kritische Sachen machst, dann kann es gut sein, dass dieser Ansatz überhaupt nicht funktioniert, weil du weil du halt sozusagen dann rauskriegst, wenn du anguckst, was ist denn die Teile deines Codes, die langsam sind, naja, dann ist er halt irgendwie Mem-Copy oder keine Ahnung, dann wird halt Hauptspeicher durch den Prozessor geschoben.

Das willst du optimieren.

Das ist halt, da kannst du nichts mehr machen.

Und da musst du eigentlich wieder ans Design deiner Applikation strukturieren.

Und wenn ich von vornherein weiß, dass das performance-kritisch ist, dann schreibe ich einen ganz anderen Code.

Dann ist der Code komplett anders eigentlich, ja, also da kannst du vergessen, da musst du komplett das Design ändern.

Genau, und da meinte dann halt auch, dann kann es sein.

Du meinst so John Kamek?

Nee, nee, der hat irgendwie so einen italienisch klingenden Namen.

Ich hab jetzt, weil ich hab's nicht mehr ganz.

Okay, I don't know.

Ja, der hängt halt davon, ob man performance-kritisch einen Kram macht oder nicht.

Und wenn man es nicht macht, dann muss man das nicht machen.

Aber wenn man, wenn man das hat und hat aber auf die falsche Art entwickelt und glaubt dann mit irgendwie Hotspots optimieren, da rauskommen zu können, dann meint er, so hat er schlechte Nachrichten.

Das kann gut sein, dass das nicht geht.

Und dass auch wenn man rausfinden möchte, jetzt, okay, was ist denn, wie muss ich denn die Architektur ändern?

Oder das Design, dann kann es sein, dass, wenn das ein Großgrußprojekt ist, das wird schlimmer als ein Rewrite, der dann, wo man im Hinterkopf hat, dass das besser auf eine Performance kritisch ist.

Und deswegen wird das in der Spielindustrie auch häufiger gemacht und es ist tatsächlich auch ab und zu erfolgreich.

In anderen Bereichen sollte man das vielleicht nicht machen, also aber da ist das halt wohl ab und zu irgendwie dann halt der beste Weg.

Und ja, tja, ja, das ist alles nicht so einfach.

Das ist gleich dein Schlusswort.

Ja, kann man immer sagen.

Hängt davon ab, kommt drauf an, das ist alles nicht so einfach.

Schönen Dank, dass wir dir zugehört haben.

Vielen Dank, Martin, dass du da warst.

Ja, nee.

Ja, was gemacht.

Schalt uns doch bald wieder rein.

Hallo at pythonpodcast.de.

Bis zum nächsten Mal.