Samuels Technologie-Landkarte
Technologie-Kompetenz lässt sich nicht aus Lebensläufen ablesen. Sie zeigt sich darin, welche Fehler jemand macht — und wie präzise er sie beschreibt. Diese Karte basiert auf dem, was in sechs Notebook-Analysen sichtbar wurde: durch Code, durch Fehlschläge, durch Fragen, durch Erklärungen.
Kernkompetenzen (Advanced)
Python — Die Muttersprache
Python läuft durch alle vier Projekte wie ein roter Faden. Nicht als Werkzeug, das man benutzt, weil es verfügbar ist — sondern als Sprache, in der man denkt.
Async/Concurrency: Keeper zeigt, was "advanced" hier bedeutet. asyncio.gather() mit Semaphores für parallele API-Calls, Event-Loop-Management, der Unterschied zwischen asyncpg und psycopg2 als bewusste Architekturentscheidung: "asyncpg ist ein asynchroner PostgreSQL-Treiber. Im Gegensatz zu psycopg2 (synchron) blockiert asyncpg nicht den Event Loop während einer Datenbankabfrage. Das heißt: Während eine DB-Query auf Antwort wartet, kann unser Server andere HTTP-Requests bearbeiten."
Gleichzeitig zeigt das fehlende await auf einem async API-Call in Keeper, dass selbst gute async-Kenntnisse gegen subtile Bugs nicht immun sind. Das ist ehrlich — kein gecasteter Skill, sondern ein lebendiger.
Einsatz in: Keeper (async pipeline), mAImory (FastAPI backend), NPU Agent (selfai.py, agent_manager.py), Self AI V2 (inference integration), SE-Studium (UML exercise scripts)
FastAPI — Produktiv ohne Boilerplate
FastAPI ist Samuels bevorzugtes Backend-Framework für neue Projekte — wegen Python-Vertrautheit, Pydantic-Integration und der automatischen OpenAPI-Dokumentation.
In Keeper wurde eine vollständige REST-API mit Swagger UI, Pydantic-Validierung, async-Endpoints und 8 Microservices aufgebaut. In mAImory war FastAPI explizit als Constraint definiert: "YES known tech stack (Python/FastAPI)" — weil Vertrautheit im 4-Wochen-MVP-Sprint wichtiger ist als technische Neuheit.
Reifer Einsatz: Modular routing, startup configuration, error handling. Noch offen: Missing-await-Bugs zeigen, dass async FastAPI Tücken hat, die auch Erfahrene treffen.
Docker und Docker Compose — Infrastruktur als Code
8 Services in einem docker-compose.yml orchestriert, mit named volumes, internem Networking (db:5432, kafka:29092, elasticsearch:9200), environment variables und health checks. Das ist nicht "ich habe Docker mal ausprobiert" — das ist produktiver Umgang mit Container-Orchestrierung auf mittlerem Komplexitätsniveau.
Cloud-Agnostizismus in mAImory: "Docker container macht den Provider irrelevant architektonisch. Flexibilität, auf Startup-Credits zu reagieren."
LLM und AI-Integration — Multi-Provider-Denken
Nicht ein LLM-Provider — mehrere, hinter Abstraktionsschichten. In mAImory wurden drei konkrete Adapter implementiert (OpenAI, Claude, MiniMax) hinter einer abstrakten LLMAdapter-Schnittstelle. In Keeper übernimmt LangGraph die Orchestrierung (Price Monitor Agent, Deal Finder Agent, Alert Dispatcher).
Das Wichtigste: Samuel denkt nicht in einzelnen API-Calls. Er denkt in Provider-Unabhängigkeit, Fallback-Ketten, Timeout-Budgets. "LLM market changes rapidly. System must support OpenAI, Claude, and MiniMax without vendor lock-in."
Aus der Praxis: "Da ich jetzt schon 6 Monate an einem eigenen KI System mit generativer KI arbeite, kenne ich aus der Praxis ein paar der Tücken die über ein solches System auftreten können."
Software-Architektur und Design Patterns — Das akademische Fundament mit Praxisankern
Das ist vielleicht die stärkste Kompetenz — und die am wenigsten offensichtliche. ADD 3.0, Adapter Pattern, Repository Pattern, Chain of Responsibility, Strategy Pattern: Diese werden nicht nur benannt, sondern angewendet und begründet.
"Hochgradige architektonische Reife. Studenten neigen oft dazu, einfach alles Coole einzubauen. Du machst das Gegenteil: Du lehnst komplexe Patterns ab und begründest das perfekt mit deinen Constraints."
Besonders stark: Trade-off-Denken. Jede architektonische Entscheidung kommt mit einer Abwägung, was dabei aufgegeben wird. "Trade-off Accepted: Sacrifice: Perfect scalability in Phase 1 — Gain: Fast market entry — Worth it: YES."
Solides Wissen (Intermediate)
PostgreSQL — Funktional, aber mit blinden Flecken
Keeper zeigt ein solides Schema-Design: UUID Primary Keys, Foreign Keys, Indizes, Multi-Tenant-Unterstützung über eine users-Tabelle, ENUM-Typen für Status-Felder. Das Dual-Schema-Problem (synchroner und asynchroner Stack nebeneinander) zeigt allerdings auch, dass Datenbankentscheidungen früh und konsequent getroffen werden müssen.
Der ehrlichste Satz kommt aus mAImory: "Leider kenne ich mich nicht mit Datenbanken aus." Das ist keine Schwäche als Geständnis — das ist Selbstkenntnis. Und der erste Schritt, sie zu adressieren.
PostgreSQL-spezifisches Wissen ist vorhanden (Row-Level Security für Multi-Tenant-Isolation, asyncpg als Treiber, pool_pre_ping für Connection Management). Migrations, Index-Optimierung und Schema-Evolution sind als Lücken identifiziert.
Apache Kafka — Konzeptuell stark, praktisch noch begrenzt
Kafka in Keeper: Consumer Groups, Offsets, Topic-basiertes Routing, 7-Tage-Retention konfiguriert. Das "Warum Kafka" ist gut artikuliert: "Das ist der Vorteil von Kafkas Architektur gegenüber klassischen Message Queues: kein Message Loss."
Was fehlt: Cluster-Erfahrung (Single-Broker-Setup), Kafka Streams, Schema Registry. Das ist One-Node-Kafka — produktiv, aber nicht Produktionsreif.
Elasticsearch — Konzeptionell verstanden, praktisch noch Einsteiger
Keeper verwendet Elasticsearch mit eigenem Analyzer (German Stemmer + ASCII-Folding), konfigurierten Shards und Replicas. Das Verständnis der Rolle ist klar: "'Zeige mir alle Deals unter 50€ mit Rating > 4.0 sortiert nach Discount' ist eine Zeile in ES, aber ein komplexer Join in SQL."
Single-Node-Setup für Development — kein Cluster-Betrieb, keine Produktionserfahrung. Explizit selbst so eingestuft: "Beginner/Intermediate".
Git und Linux — Tägliches Handwerk
Pop!_OS mit COSMIC Desktop als tägliche Arbeitsumgebung, apt-Paketverwaltung, Systemhärtung, Kommandozeile. Git als Standard-Tool für alle Projekte. Keine Besonderheiten — aber solide Grundlage.
Privacy und Security — Eine eigene Kategorie
Ein unerwartetes, tiefes Interessensgebiet: Tor-Netzwerke, VPN-Konfiguration, VeraCrypt-Verschlüsselung, Tails OS, DNS-over-HTTPS, MAC-Adress-Randomisierung, Browser-Fingerprinting-Schutz, Kryptowährungsprivatsphäre (CoinJoin, Monero).
Das Wichtigste dabei ist eine philosophische Grundhaltung: "Anonymität beginnt nicht im Netz — sie beginnt im Kopf." Und: "Wissen ist kein Schutz. Verhalten ist Schutz."
Grundlagen (Beginner / Akademisch)
UML — Konzepte klar, Notation in Entwicklung
Software Engineering Kurs an der HS Worms: Alle 5 UML-Diagrammtypen des Kurses durchgearbeitet (Use Case, Activity, Class, Sequence, State). Konzepte verstanden — Notation noch fehleranfällig.
Der zentrale Satz: "Konzepte habe ich alle verstanden, aber einzelheiten nicht, notierung und feinheiten."
Ein konkreter Fehler: Ein Horizontal-Flow-Diagramm wurde als "Sequence Diagram" etikettiert, obwohl es ein Communication Diagram war. Inhalt korrekt, Label falsch. Wird mit der Zeit besser — braucht einfach mehr Übung mit Stift und Papier.
Cloud Computing — Akademisch solide
IaaS/PaaS/SaaS, die 5 Key Characteristics nach NIST, Public/Private/Hybrid/Community Cloud, Virtualisierung (VMs vs. Container). Korrekte Einordnung realer Dienste: Office 365 ist SaaS + Public Cloud, internes Sozialnetzwerk ist Private Cloud. Solides akademisches Fundament für praxisrelevante Architekturentscheidungen.
NPU / Hardware-Level — Versucht, gescheitert, gelernt
Das komplette Hexagon V73 Programmer's Reference Manual (Hardware-ISA-Dokumentation, 400K+ Zeichen) durchgearbeitet. Verständnis von QNN SDK, ONNX Runtime Execution Providers, CMAKE-Build-System für Hardware-Backends, ARM64 vs. x64 Kompatibilitätsmatrizen.
Praktisch: Nichts funktioniert. Aber die Lektion ist klar: "Hardware-Integration ist ein R&D-Task: Die Nutzung von LLM-Bibliotheken mit spezifischer, neuer Hardware sollte nicht als einfacher Implementierungsschritt betrachtet werden."
Woher gelernt?
| Quelle | Was davon |
|---|---|
| Hochschule Worms (Software Architecture, SE) | ADD 3.0, UML, Cloud Computing, Scrum, Design Patterns |
| Eigene Projekte (Trial-and-Error) | Async Python, Kafka, Elasticsearch, FastAPI, Docker |
| NotebookLM als Lernpartner | Strukturierte Examen-Vorbereitung, Architektur-Coaching |
| Hardware-Dokumentation (Qualcomm) | NPU, QNN SDK, ARM64-Architektur |
| Privacy-Handbook | Tor, VPN, VeraCrypt, Krypto-Privacy |
| 6 Monate GenAI-Praxis | LLM-Integration, Provider-Abstraktion, API-Rate-Limiting |
Luecken und Wachstumsfelder
Datenbankdesign ist die klar identifizierte Lücke. Migrations (Alembic), Index-Optimierung, Schema-Evolution, normalisiertes Design — das alles existiert als Konzept, aber noch nicht als praktische Routine. "Ich habe Angst vor diesen beiden sachen." — Das ist der Ausgangspunkt. Angst benennen ist der erste Schritt.
UML-Notation muss von konzeptuellem Verständnis zu Notations-Präzision wachsen. Das braucht Wiederholung mit echten Diagrammen, nicht nur Lesen.
Präsentations- und Zeitmanagement — eine Probepräsentation war 3x zu lang. "Ich bin Faktor 3 über der Zeit, daran muss ich arbeiten." Die Diagnose ist richtig: Der Unterschied zwischen "alles erklären" und "das Entscheidende kommunizieren."
NPU / Hardware-Integration — bleibt ein offenes Feld. Das Wissen ist angesammelt, die Umsetzung scheiterte an unreifer Toolchain. Wenn Qualcomm seine SDKs stabilisiert, ist der Wissensfundus vorhanden, um es erneut zu versuchen.
Cluster-Betrieb (Kafka, Elasticsearch) — Produktions-Deployment mit mehreren Nodes ist konzeptuell bekannt, aber nicht praktisch erfahren.
Tech-Stack-Evolution
Anfang Heute
------ -----
Python (Basics) → Python (Async Expert)
Einzelne API-Calls → Multi-Provider mit Adapter Pattern
Einzelne Skripte → 8-Service Docker-Compose-Systeme
Kein Architektur-Framework → ADD 3.0, ADRs, QAW, 4+1 Views
Lokaler Code → Event-Streaming mit Kafka
SQL-Grundlagen → PostgreSQL + Elasticsearch (dual)
"LLM verwenden" → LLM orchestrieren (LangGraph, Fallbacks)
Das Muster: Vom Einzeltool zum System-Denker. Von "es funktioniert" zu "warum funktioniert es, was kostet es, was passiert wenn es ausfällt."
Der nächste Schritt ist sichtbar: von der Architekturplanung zur Implementierungssicherheit — besonders bei Datenbanken und Produktions-Deployment.
Quellen: Notebooks Keeper_Amazon, Keeper_System, AI_NPU_Agent, mAImory, Software_Architecture (SWA 506), SE_Fundamentals, Self_AI_V2, Digital_Anonym — analysiert am 2026-03-02.