A.3. Meine Entwicklungsumgebung
Dieser Anhang beschreibt meine private Entwicklung: Geräte, Virtualisierung, Werkzeuge und den Einsatz von KI, soweit ich sie selbst einsetze.
Er gibt nicht wieder, womit ich beruflich arbeite. Arbeitsmittel, die ein Arbeitgeber oder ein Kunde bereitstellt, gehören nicht hierher. Ich veröffentliche hier bewusst keine Informationen, die geschützt oder als rein intern gekennzeichnet sein könnten.
Die einzelnen Abschnitte sind bewusst knapp gehalten und werden nach und nach ergänzt.
Die Arbeit verteilt sich auf lokale Arbeitsplätze, einen eigenen Linux-Server und gehostete vServer.
Als Arbeitsplätze nutze ich ein MacBook Pro (extern) 
und einen Mac mini (extern)
. Beide sind M1-(Pro)-Macs und dienen der täglichen Arbeit: Editor, lokale Builds, Browser und der Zugriff auf Server und Repositories.
Zusätzlich betreibe ich einen Intel-basierten Linux-Server mit einer Nvidia RTX 5060 (extern)
(16 GB VRAM). Er dient dem lokalen Hosting von Software wie Guacamole (extern) 
, Ollama (extern)
mit Open WebUI (extern)
und weiteren Diensten, jeweils per Docker.
Öffentlich erreichbare Dienste liegen auf Intel-basierten vServern. Dort läuft unter anderem das Hosting dieser Seite.
Dienste kapsle ich mit Docker (extern)
/Rancher (extern)
. Rancher ist dabei der Open-Source-Ersatz für Docker. Werkzeuge, Dateien und der Alltag sind dieselben, deshalb nenne ich beides zusammen.
Die Dienste sind in Projekte unterteilt. In jedem Projekt liegt eine docker-compose.yml. Darin stehen die zusammengehörigen Container, ihre Verbindungen und ihre Konfiguration. Die Projekte nutzen jeweils eigene virtuelle Netzwerke und sind damit voneinander getrennt. Nach außen dient Caddy (extern)
als Proxy.
Die Administration bleibt damit einfach: ein Projekt starten, stoppen oder aktualisieren heißt, die zugehörige Compose-Datei zu verwenden. Einzelne Container muss ich dafür nicht von Hand zusammenstecken.
Ob etwas lokal, auf dem Linux-Server oder auf einem vServer läuft, ändert an diesem Ablauf wenig. Dieselbe Projektstruktur und dieselben Compose-Dateien tragen die Dienste über die Umgebungen.
Je nach Aufgabe wechsle ich zwischen drei Umgebungen:
- Cursor (extern)
als KI-zentrierte Variante von VS Code
- IntelliJ (extern)
für Java und die damit verbundenen Werkzeuge
- Visual Studio Code (extern)
für leichtere oder sprachübergreifende Arbeiten
Welche Umgebung ich wähle, hängt vom Projekt, von der Sprache und davon ab, wie stark ich die KI in den Ablauf einbinden will.
KI ist Teil meiner täglichen Arbeit, nicht nur ein gelegentliches Nachschlagewerk. Mein Hauptwerkzeug dafür ist Cursor Pro+ (extern)
. Ergänzend nutze ich ChatGPT Plus (extern)
; GitHub Copilot (extern)
nur gelegentlich.
Cursor Pro+ (extern)
ist mein Hauptwerkzeug für KI-Aufgaben. Dateien, Git, Agent und der laufende Code liegen in einer Umgebung.
Die Nutzung umfasst vieles: Softwareentwicklung, sowohl Neuentwicklung als auch Analyse und Anpassung von Altprojekten. Dazu kommen die Auswertung von Logfiles sowie die Verwaltung und Auswertung dynamisch anfallender Daten.
Der große Vorteil: Cursor indiziert die Dateien des Projekts. Die KI kommt dadurch deutlich besser und schneller an die Informationen aus dem Projekt, statt passende Ausschnitte jedes Mal von Hand nachreichen zu müssen.
Bei den Kosten habe ich gute Erfahrungen gemacht, vor allem mit dem Auto-Modus bei der Modellwahl. Auto wählt das Modell passend zur Aufgabe. Die Token-Kosten bleiben überschaubar: selbst bei intensiver täglicher Nutzung reichen die inklusiven Token derzeit aus.
ChatGPT Plus (extern)
nutze ich inklusive Codex (extern)
vor allem für einfache Anfragen zu verschiedenen Themen. Daneben setze ich es gezielt zur Unterstützung bei der Administration meiner Systeme ein.
GitHub Copilot (extern)
nutze ich gelegentlich, vor allem dort, wo ich in IntelliJ oder VS Code bleibe. Im Vergleich zu den anderen Werkzeugen war die Erfahrung eher ernüchternd.
Der Auto-Modus von Copilot ist extrem schwach. Meine Empfehlung: immer explizit ein Modell wählen. Als Standard ein halbwegs kostengünstiges Modell, bei komplexen Anfragen manuell auf ein teures Modell wechseln.
Aus Kostensicht war Copilot enttäuschend. Es hat sehr viele Token verbraucht und damit deutlich höhere Kosten verursacht als etwa Cursor.
Auch bei privaten Projekten setze ich auf Microservices (extern)
und Domain-Driven Design (DDD) (extern)
. Die Dienste laufen in denselben Docker/Rancher-Projekten wie oben: lokal, auf dem Linux-Server oder auf einem vServer.
Lange Zeit habe ich privat in Java entwickelt, mit Spring Boot (extern)
oder Quarkus (extern)
. Inzwischen ist Go (extern)
die Sprache meiner privaten Anwendungen.
Der Wechsel hat vor allem zwei praktische Gründe: große, komplexe Frameworks vermeiden und native Images für ARM64 und AMD64 bereitstellen, ohne eine JVM.
Hinzu kommt das Ergebnis eines Tests: Software mit professionellem Anspruch zu schreiben, ohne Jahre oder Jahrzehnte Erfahrung in der Sprache gesammelt zu haben. Diesen Punkt führe ich später gegebenenfalls genauer aus.
Auf der Clientseite habe ich mich für eine Integration in Nextcloud (extern)
entschieden. Zuvor nutzte ich React (extern)
mit MUI (extern)
und Keycloak (extern)
als OpenID-Connect-Anbieter (OIDC).
Ich schreibe private Anwendungen in erster Linie für mich und meinen eigenen Gebrauch. Nextcloud übernimmt die Nutzer- und Rechteverwaltung und bietet einheitliche APIs, etwa für den Dateizugriff. Eine eigene Oberfläche und ein eigener Identity-Provider lohnen sich dafür nicht.
Die Anwendungen selbst sind Go-HTTP-Dienste, die als ExApp hinter AppAPI (extern)
und HaRP (extern)
laufen. Keine klassischen PHP-Apps, kein Python-ExApp-SDK.
| Schicht | Nutzung |
|---|---|
| AppAPI | Registrierung, Deploy und Lifecycle (/heartbeat, /enabled, …). Die Beschreibung steht in info.xml (routes, environment-variables, Docker-Image). |
| HaRP | Deploy Daemon und Gateway: Browser → /exapps/… → ExApp-Container. |
| ExApp-Image | OCI-Image ({registry}/{owner}/{exapp-id}), Deploy durch AppAPI/HaRP. |
| API | Zweck |
|---|---|
| AppAPI Auth (extern)
|
Shared Secret und Header (AUTHORIZATION-APP-API, EX-APP-ID, …); Impersonation des anfragenden Nutzers. |
OCS (extern)
(/ocs/v2.php/…, format=json) |
Preferences, Notifications, Top-Menu-Registrierung, Users und Groups. |
| WebDAV (extern)
|
Nextcloud Files als anfragender Nutzer (/remote.php/dav/files/{user}/). |
Notifications laufen über den AppAPI-Notification-Endpunkt, nicht über das generische Notifications-OCS der Notifications-App.
Lokal liegt das Compose-Projekt unter /docker: Caddy, Nextcloud, HaRP, Datenbank, Redis und weitere Basisdienste. Die ExApps sind keine dauerhaften Compose-Services. Sie laufen als von HaRP deployte Container.
- klassische Nextcloud-PHP-Apps (
OCP*) - das offizielle Python-ExApp-Ökosystem (
nc_py_apiund Vergleichbares) als Basis
Übersicht der externen Verweise auf dieser Seite. Neue, geänderte oder entfernte Links im Text werden hier mitgeführt.