Sidecar/knowledge/gemini_TechStack.md

# 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.*