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