Coding-Workshop: Report-Endpunkt mit FastAPI und SQLAlchemy umgesetzt

Der Stream beginnt mit einer lockeren Begrüßungsrunde, in der Zuschauer einzeln willkommen geheißen werden. Es wird über das vergangene Wochenende gesprochen, unter anderem über lange Arbeitstage am Freitag und eine Beschäftigung mit Minecraft. Außerdem wird angesprochen, dass der Streamplan für die kommende Woche erstellt wurde und ein Test mit einem späteren Start um 19.30 Uhr ansteht.

Neuerungen am Waiting Screen und spätere Startzeit

00:09:03

Es wird darauf eingegangen, dass ein Fehler im Waiting Screen behoben wurde, was offenbar niemandem aufgefallen ist. Die spätere Streamstartzeit wird als bewusste Entscheidung erklärt, um den Sonntag entspannter zu gestalten. Zudem wird eine Krankmeldung eines Zuschauers kommentiert und gute Besserung gewünscht, bevor das Gespräch auf ein kürzlich veröffentlichtes Reel über Browser lenkt.

Ein kürzlich veröffentlichtes Video über Browser wird thematisiert, in dem die langjährige Unzufriedenheit mit Chrome wegen hohen RAM-Verbrauchs erklärt wurde. Viele Kommentare schlugen vor, doch die Einstellungen anzupassen, was jedoch als naheliegend und bereits bedacht zurückgewiesen wird. Es wird erläutert, dass ein Wechsel zu einem Nischen-Browser nicht infrage kommt, da Synchronisation zwischen MacBook und Handy gebraucht wird.

Für den Stream wird ein anderer Browser genutzt als privat, um zu verhindern, dass private Daten wie Autofill-Einträge versehentlich im Stream sichtbar werden. Aktuell kommt Brave für den Stream zum Einsatz, während die Tabs privat auf Firefox übertragen wurden. Dabei wurde festgestellt, dass Firefox trotzdem viel RAM verbraucht, weshalb ein Plugin zum Pausieren ungenutzter Tabs hinzugefügt wurde, das den Verbrauch deutlich reduzierte.

Ein größerer Exkurs dreht sich um die Aussprache von IT-Begriffen wie Opera, Azure, API, CAT, GIF, Python, Linux, SQL und LaTeX. Es wird reflektiert, dass viele Fachbegriffe nur gelesen und geschrieben, aber selten ausgesprochen werden, was zu Unsicherheiten führt. Die Anpassung an die deutsche oder englische Aussprache des jeweiligen Umfelds wird als übliche Strategie beschrieben, während bei Amazon bewusst die deutsche Aussprache beibehalten wird.

Erfahrungen mit der AWS-Kooperation

00:14:52

Die Zusammenarbeit mit AWS wird ausführlich beleuchtet, wobei betont wird, dass über Kooperationen im Stream selten gesprochen wird. Die Abwicklung zog sich über Wochen und war wegen der Kommunikation mit einer US-Agentur und der Zeitverschiebung sehr stressig. Es wird die Frage aufgeworfen, wie Fulltime-Creator mit solchen Kooperationen umgehen, und es wird erklärt, dass die Zusammenarbeit sich eher wie ein Projekt anfühlte, aber mit spürbarem Druck verbunden war.

Geplanter AWS-Hackathon und Umgang mit Kritik

00:24:03

Es wird angekündigt, dass demnächst gemeinsam mit AWS ein Hackathon stattfinden soll. Überraschenderweise fiel die Kritik an der AWS-Kooperation geringer aus als erwartet, obwohl AWS nicht überall beliebt ist. Im Vergleich dazu gab es bei einer früheren Kooperation für einen Microsoft-Hackathon mehr Gegenwind, obwohl dort nur für den Hackathon und nicht für Microsoft selbst geworben wurde.

Es wird erklärt, dass im Oktober drei Kooperationen angenommen wurden, deren Abwicklung bis in den aktuellen Monat hinein stressig war. Für die Zukunft sollen Kooperationen reduziert werden, wobei Marken auf einer inneren Whitelist stehen, für die sofort Werbung gemacht wird. Als Beispiel wird Logitech genannt, bei dem die Produkte privat geschätzt werden, sodass eine Zusammenarbeit ohne großes Zögern eingegangen wird.

Der Aufwand von Creator-Kooperationen wird anhand des Beispiels von Werbung für Getränkemarken verdeutlicht, bei denen teilweise mehrfach pro Stream Produkte in die Kamera gehalten werden müssen. Derartige vertragliche Verpflichtungen werden als sehr arbeitsintensiv beschrieben und es wird angemerkt, dass im eigenen Stream gar nicht so viel getrunken wird, um solche Vorgaben zu erfüllen. Zudem wird auf die möglicherweise platzende KI-Blase und sinkende Preise angesprochen.

Anekdote über Einbruchsversuch am eigenen Auto

00:28:59

Eine persönliche Geschichte handelt von einem versuchten Einbruch in das eigene Auto, bei dem die Täter nicht hineinkamen und aus Frust die Reifen zerstochen haben. In derselben Zeit wurden im Wohnort viele moderne Autos mit Keyless-Go aufgebrochen, indem Signale abgefangen wurden. Das eigene Auto blieb wegen fehlender Keyless-Go-Technik sicher, was zu einem scherzhaften Vergleich zwischen Dieben und Fahrzeug geführt habe.

Vorfreude auf Frank Thelen bei Schlag den Star

00:33:18

Für den kommenden Samstag um 20.15 Uhr wird angekündigt, die Sendung Schlag den Star anzuschauen, weil Frank Thelen dort als Kandidat auftritt. Es wird gescherzt, dass wilde Aussagen über IT und KI zu Clips verarbeitet werden sollen, und es wird gehofft, dass er tatsächlich über diese Themen spricht. Zuschauer werden ermutigt, die Sendung gemeinsam im Discord zu verfolgen und eigene Clips zu erstellen.

Nach einer Pause wird an das Coding-Projekt angeknüpft, wobei rekapituliert wird, dass zuletzt Lambec eingerichtet und mit Python SQL geschrieben wurde. Das aktuelle Ziel besteht darin, dass ein Post-Report die Meldung in der Tabelle speichert und sie mit der echten ID aus der Datenbank zurückgibt. Während des Lesens der Anleitung wird immer wieder betont, dass nicht alles sofort verstanden werden muss.

Erklärung des Endpunkts und der Datenbanklogik

00:38:19

Es wird schrittweise erklärt, wie FastAPI das JSON gegen ReportCreate prüft und der Endpunkt über DependsGetDB eine Session erhält. Ein Objekt der Datenbankklasse Report wird erstellt und mit Werten befüllt, wobei ID, Status und CreatedAt von der Datenbank über Standardwerte gesetzt werden. Die Begriffe DB-Add, DB-Commit und DB-Refresh werden erläutert, wobei besonders betont wird, dass ohne Commit alle Änderungen beim Schließen der Session verworfen werden.

Exkurs über Energydrinks und KI-Marketing

00:42:41

Eine kurze Unterbrechung dient dazu, einen Energy-Drink der Sorte Disco Crumble zu probieren, der als überraschend lecker beschrieben wird. Die Marketingtexte auf der Dose werden als typisch KI-generiert analysiert, mit Phrasen wie Apfel MC und Zimtmaster Flash, die den Flavor-Regler aufdrehen. Es wird scherzhaft empfohlen, das Getränk nicht zu kaufen, um keine Abhängigkeit zu entwickeln.

Der Coding-Ablauf wird fortgesetzt mit der Erklärung, dass DB-Refresh die Zeile frisch aus der Datenbank zurückliest, damit das Python-Objekt die von der Datenbank erzeugten Werte kennt. Anschließend wird aus dem Datenbankobjekt ein ReportResponse erzeugt, wobei Pydantic über Model Validate und from Attributes die Werte aus den Attributen liest. Zudem wird das Konzept Expire on CommitFaults erklärt, bei dem SQLAlchemy nach jedem Commit Werte als veraltet markiert und in asynchronem Code heimliche Nachladungen zu Fehlern führen.

KI-generierte Bilder bei Lieferando

00:48:56

Ein ausführlicher Exkurs behandelt KI-generierte Bilder bei Lieferando, bei denen Speisen anhand des Titels dargestellt werden, ohne dass die Kategorie oder Beschreibung berücksichtigt wird. Dadurch entstehen absurde Darstellungen, etwa ein Puzzle statt einer Pizza Hawaii. Es wird kritisiert, dass niemand diese Bilder kontrolliert, während KI-Unterstützung bei Fotos, die lediglich professioneller aussehen sollen, als unproblematisch angesehen wird.

Grenzen von KI in Games und bei Jobverlusten

00:59:03

Es wird klargestellt, dass KI-Unterstützung in vielen Bereichen in Ordnung ist, solange niemandem dadurch ein Job weggenommen wird, der ohnehin besetzt worden wäre. Große Game-Studios, die KI-Assets verwenden, werden dagegen scharf kritisiert, da sie sich echte Künstler leisten könnten. Die Diskussion zeigt eine differenzierte Haltung, die KI als Werkzeug akzeptiert, aber ihren Missbrauch durch finanziell starke Akteure ablehnt.

Verwirrung um Variablennamen und Modellzuordnung

01:00:28

Beim Coding kommt es zu anhaltender Verwirrung über die Namen Report, ReportCreate und DB-Report sowie darüber, welche Klasse an welcher Stelle referenziert wird. Es wird mehrfach versucht, die Zuordnung von Pydantic-Modellen, SQLAlchemy-Klassen und Response-Schemas nachzuvollziehen, wobei das Verständnis immer wieder ins Stocken gerät. Die Moderation ermutigt dazu, Fragen zu stellen und gemeinsam nachzuvollziehen, statt alles allein verstehen zu müssen.

Reaktionen auf Social Media und Hater-Kommentare

01:09:01

Ein Kommentar auf TikTok bezeichnet die Nutzung von Chrome und Claude als IT-LARP, was amüsiert zur Kenntnis genommen wird. Zudem wird eine Instagram-DM eines neuen Haters vorgelesen, der aufgrund einer Dockernummer die IT-Kompetenz infrage stellt, worauf humorvoll reagiert wird. Die Moderation zeigt sich gelassen und nutzt die Kommentare als Anlass für scherzhafte Selbstironie.

Vertiefung in die FastAPI- und Pydantic-Logik

01:20:20

Es wird weiter versucht, die Funktionssignatur von NewReport zu durchdringen, bei der FastAPI den JSON-Body gegen das Pydantic-Modell prüft, bevor die Funktion überhaupt startet. Die Prüfung der Kategorie gegen die erlaubten Werte und die Längenprüfung der Description werden nachvollzogen. Gleichzeitig wird eingeräumt, dass das Setup komplex ist und das Gehirn an manchen Stellen die Mitarbeit verweigert.

Die Rolle der Base-Klasse in Base.py wird erklärt, die selbst leer ist, aber die SQLAlchemy-Technik von DeclarativeBase erbt und als gemeinsame Basis für alle Tabellen dient. Report erbt von Base und wird dadurch zu einer Tabelle namens Reports mit den entsprechenden Spalten. Zudem wird erläutert, warum Report Category und Description funktioniert, obwohl keine entsprechende Funktion geschrieben wurde.

KI als Blackbox und Verantwortung von Entwicklern

01:28:34

Es wird diskutiert, dass bei vielen parallel laufenden Agenten die KI als Blackbox betrachtet werden muss, aber dennoch ein Grundverständnis und Kontrolle über den Code notwendig bleiben. Die KI macht Fehler, und der Mensch muss die Person sein, die den Code prüft und Verantwortung übernimmt. Es wird betont, dass Vertrauen in KI zum aktuellen Zeitpunkt nicht gerechtfertigt ist und dass lesbarer Code eine wichtige Kontrollmöglichkeit darstellt.

Es wird geklärt, dass NewReport nur die Parameter Report und DB kennt und die Werte über Keyword-Argumente wie Description=Report.Description und Category=Report.Category übergeben werden müssen. Die Reihenfolge spielt dabei keine Rolle, da die Namen ausschlaggebend sind. Zudem wird erwähnt, dass ein nicht mehr benötigter Import entfernt werden kann, weil die ID jetzt von der Datenbank kommt.

Grundsatzrede gegen die Ersetzung von Programmierern durch KI

01:34:36

Eine ausführliche und emotionale Passage widmet sich der Behauptung, KI werde Programmierer ersetzen. Es wird argumentiert, dass Programmierer keine Code-Äffchen sind, sondern Verantwortung für ihren Code übernehmen und Architekturentscheidungen treffen müssen. KI kann keine Haftung übernehmen, keine neuen kreativen Lösungen schaffen und kennt keine Pain Points von Kunden, weshalb sie menschliche Entwickler nicht ersetzen kann.

Grenzen von KI und wirtschaftliche Fehlannahmen

01:41:41

Es wird erklärt, dass KI nur vorhandene Inhalte neu zusammensetzen kann und ohne menschliche Kreativität langfristig an Grenzen stößt. Wenn alle Entwickler durch KI ersetzt würden, gäbe es keine neuen Lösungen für neue Fehler, und alles würde gleich aussehen. Zudem wird auf Berichte verwiesen, wonach Unternehmen in den USA Entwickler wieder einstellen mussten, weil die Idee, sie durch KI zu ersetzen, gescheitert ist.

KI vs. Mensch: Haftung, Empathie und Kontext

01:46:01

Die Diskussion vertieft den Vergleich zwischen KI und Mensch und betont, dass ein Mensch Charakter, Empathie und Erfahrung besitzt, die eine KI nicht hat. Selbst bei einfachen Data-Entry-Aufgaben kann ein Mensch Fehler erkennen, die eine Automation übersieht, weil Kontextwissen und Alltagserfahrung fehlen. Zudem wird das Beispiel eines KI-Agenten genannt, der in neun Sekunden trotz Verbot eine Datenbank samt Backups gelöscht haben soll.

Kritik am Vibecoding und fehlender Kontrolle

01:53:03

Vibecoding wird als problematisch beschrieben, weil dabei der Kontakt zum Code verloren geht und Nutzer nicht überprüfen können, was die KI erzeugt hat. Es wird das Szenario beschrieben, dass jemand per Prompt eine App baut und veröffentlicht, ohne Sicherheitslücken oder Datenbankfehler erkennen zu können. Die KI ist ein Werkzeug, wird aber von vielen als Wunderlösung missverstanden, was zu gefährlichen Ergebnissen führt.

Nach einer kurzen Verabschiedungsphase wird diskutiert, dass KI immer nur die wahrscheinlichste Antwort berechnet und kein Konzept von Wahrheit besitzt. Eine KI redet dem Nutzer nach dem Mund, wenn sie nicht explizit angewiesen wird, ehrlich zu sein, und sie kennt keine Skrupel, wenn es der Aufgabe dient. Es wird empfohlen, der KI klarzumachen, dass Wahrheit wichtiger ist als Freundlichkeit.

Definition von Vibecoding und Refactoring mit KI

01:59:03

Vibecoding wird als Zustand definiert, in dem kein Kontakt mehr zum Code besteht und die KI unkontrolliert arbeiten lässt. Wer den Code überprüfen und Fehler selbst erkennen kann, betreibt laut dieser Definition kein Vibecoding mehr. KI wird vor allem beim Refactoring als nützlich beschrieben, wenn bereits funktionierender Code vorliegt, während Fragen nach dem besten Werkzeug oft keine eindeutige Wahrheit haben.

Der Coding-Teil kehrt zurück zur praktischen Umsetzung, wobei ein nicht mehr benötigter Import entfernt wird und anschließend ein Post-Report über die API ausprobiert wird. Die Meldung wird abgeschickt, und nach einem kurzen Schreckmoment zeigt sich, dass der Eintrag erfolgreich in der Tabelle Reports gespeichert wurde. Damit ist der vollständige Weg von der Anfrage über die Validierung bis zur Datenbank erstmals durchlaufen.

Reaktionen auf KI-Skepsis und Anwendungsfälle

02:04:30

Es wird klargestellt, dass die Haltung gegenüber KI nicht ablehnend ist, sondern sich gegen Schwarz-Weiß-Denken richtet. Kritisiert werden sowohl KI-Ultras, die jede Entscheidung auslagern, als auch pauschale Ablehnung. Das eigene Coding-Projekt dient als Beispiel dafür, KI zu nutzen, aber den Code dennoch selbst zu verstehen, weil das Knobeln und Rätseln Teil der Motivation ist.

Ein Beispiel eines Creators wird diskutiert, der per Vibecoding Apps in den App-Store gebracht hat, darunter eine App, mit der sich Bilder von Tieren generieren lassen, wobei jede Generierung Geld kostet. Es wird hinterfragt, warum Menschen für so etwas zahlen, obwohl ein Referenzbild ausreichen würde. Zudem wird über eine Fitness-App gesprochen, die Kalorien anhand von Fotos schätzen soll, aber unrealistisch funktioniert.

Soziale Risiken von KI als Gesprächspartner

02:08:54

Es wird thematisiert, dass KI bei Streitigkeiten dem Nutzer nach dem Mund redet und sogar Diagnosen wie Narzissmus stellt, was soziale Probleme verursachen kann. In die andere Richtung kann eine KI negative Selbstbilder verstärken und eine Abwärtsspirale auslösen, wenn Nutzer ständig über sich selbst schimpfen. Guardrails sollen solche Effekte verhindern, doch KI macht Fehler.

Es wird eingeräumt, dass sich das Denken mit KI stärker auf die Architekturebene verschiebt und triviale Codeschnipsel abgegeben werden können. Dennoch bleibt es notwendig, den Code zu verstehen und bewerten zu können, weil sonst Architekturentscheidungen nicht fundiert getroffen werden können. Wer KI nutzt, muss weiterhin die Kontrolle behalten und die Fähigkeit besitzen, Lösungen zu bewerten.

Kritik an unseriösen Vibecoding-Apps

02:12:10

Es wird auf einen Creator verwiesen, der zahlreiche Apps auf den Markt bringt, unter anderem eine Fitness-App, die laut Kritik nicht funktioniert. Das Vorgehen wird als Beispiel dafür gesehen, wie ITler sich selbst ins schlechte Licht rücken, wenn sie sich als Vibecoder inszenieren und unsinnige Apps veröffentlichen. Es wird scherzhaft angedeutet, dass man die Apps des Creators genauer untersuchen könnte, was aber an der iPhone-Beschränkung scheitert.

Fortsetzung der Coding-Erklärung und erster Datenbankeintrag

02:24:24

Nach einer kurzen Pause wird die Erklärung fortgesetzt, dass ID und Status mit der Datenbank übereinstimmen und der erste Eintrag erfolgreich gespeichert wurde. Damit könnte ein Client einen Report abschicken und dieser würde in der Datenbank landen. Es wird angekündigt, dass alle weiteren Funktionen auf diesem Muster aufbauen werden.

Serverseitige Prüfungen und SQL-Injection

02:27:02

Es wird erläutert, dass FastAPI die Meldung prüft, SQLAlchemy sie speichert und die Datenbank die ID vergibt. Auf Nachfrage wird geklärt, dass die serverseitige Prüfung gegen das Pydantic-Modell läuft und die Category nur bestimmte Werte annehmen darf, während die Description bisher nur auf Zeichenlänge geprüft wird. Eine mögliche Prompt-Injection unter 2000 Zeichen würde derzeit noch nicht ausgeschlossen, und SQL-Injection wird als ähnlich funktionierender Angriff auf anderer technischer Ebene erklärt.

Neuer Endpunkt für einzelne Reports mit 404-Behandlung

02:32:33

Ein neuer Endpunkt wird geschrieben, der einen Report anhand seiner ID lädt und bei fehlendem Eintrag eine HTTP-Exception mit 404 auslöst. Dabei wird betont, dass Raise statt Return verwendet wird, damit die Funktion sofort abbricht. Zudem wird die Soft-Delete-Logik angesprochen, bei der ein gesetztes DeletedAt ebenfalls als nicht gefunden behandelt werden soll.

Soft-Delete-Bedingung und Gespräch über WoW

02:35:48

Die Bedingung des Endpunkts wird um den Fall erweitert, dass DeletedAt nicht None ist und der Report als gelöscht gilt. Parallel wird über World of Warcraft gesprochen, wobei eingeräumt wird, keine Ahnung von MMORPGs zu haben und lieber storybasierte Spiele zu mögen. Es wird erklärt, dass Open-World-Spiele wie Skyrim bevorzugt werden.

Es wird über eine Creatorin gesprochen, die nach der Veröffentlichung ihrer Verlobung viele Follower verloren hat, was auf Zuschauer hindeutet, die sich Chancen ausgerechnet hatten. Diese Reaktion wird als traurig und bezeichnend für parasoziale Erwartungen bewertet. Es wird vorgeschlagen, Beziehungsstatus aus Prinzip öffentlich zu machen, um solche Weirdos auszusortieren.

Geld als Erwartungsdruck bei Streamerinnen

02:44:45

Es wird diskutiert, dass manche Zuschauer nach Korb oder Ablehnung mit finanzieller Unterstützung argumentieren und erwarten, dass Streamerinnen etwas zurückgeben. Unterstützung wird als freiwillig und die Gegenleistung als der Stream selbst beschrieben. Zudem wird die Frage aufgeworfen, warum männliche Creator solche Probleme seltener haben und wie sich das mit dem Geschlecht und der Erwartungshaltung von Zuschauern verhält.

Der neue Endpunkt wird in der API-Dokumentation getestet, indem eine vorhandene Report-ID eingegeben und anschließend eine ungültige ID verwendet wird. Bei der ungültigen ID erscheint korrekt die 404-Fehlermeldung. Wird ein Zeichen ausgetauscht, sodass keine gültige UUID mehr vorliegt, liefert FastAPI erwartungsgemäß einen 422-Fehler.

Update der Testmeldung auf deleted_at

02:49:18

Es wird versucht, die Testmeldung über ein SQL-Update mit einem DeletedAt-Zeitstempel zu versehen, wobei die genaue Syntax in Erinnerung gerufen werden muss. Geplant ist der Ausdruck Current Timestamp für die Spalte DeletedAt, gefiltert über die ID. Die Umsetzung gestaltet sich etwas holprig, weil SQL-Kenntnisse eingerostet sind.

Es wird berichtet, dass selbst kleine Creatorinnen Nachrichten wie Anfragen nach getragenen Socken erhalten, während männliche Creator in vergleichbarer Größe solche Nachrichten seltener bekommen. Die eigene Strategie besteht darin, sich nicht in Party-Outfits zu zeigen, um solche Anfragen zu reduzieren. Es wird überlegt, ob manche Absender Trolle sind und wie man reagieren sollte.

Klärung zur Formulierung über freizügige Kleidung

02:54:54

Eine Aussage im Chat, wonach freizügige Kleidung entsprechende Menschen anzieht, wird als missverständlich formuliert kritisiert, da sie so klingen könnte, als trage die Person selbst die Schuld. Es wird klargestellt, dass Menschen sich unabhängig von Kleidung angemessen verhalten können und dass niemand sein Verhalten mit der Kleidung anderer rechtfertigen kann. Diese Klarstellung wird ausdrücklich als wichtig erachtet, ohne dem Chatteilnehmer eine schlechte Absicht zu unterstellen.

Abschluss des Soft-Delete-Tests und Verabschiedung

02:55:52

Das Update mit Current Timestamp wird ausgeführt, und der Report wird erneut abgefragt, um zu prüfen, ob der Soft-Delete-Fall korrekt 404 liefert. Zudem wird die Reihenfolge der Bedingungen im Endpunkt erklärt, da bei umgekehrter Reihenfolge ein 500-Fehler statt 404 auftreten würde. Nach über drei Stunden Streamzeit wird der Stream beendet und ein Raid zu Bastelnerd angekündigt, der KI auf einem selbstgebauten PC installiert.