Für unsere Applikationsentwicklung habe ich die kanonische Anwendung als Open Source Projekt auf Github zur Verfügung gestellt. Dabei handelt es sich um ein kleines Beispiel mit einer vorgeschalteten Nginx als Web-Server und Reverse Proxy, einem nativen Quarkus Microprofile Applicationsserver und einer mysql Datenbank.

Dieses Beispiel wir bei jedem Push des Source Codes automatisch gebaut, getestet, auf einen Staging Server hochgeladen und gestartet, siehe CD/CD. Die Dokumentation wird bei diesem Vorgang ebenfalls automatisch aus dem Code erstellt und in Github Pages eingespielt. Wenn das Ergebnis zufriedenstellen ist, wird es mit kubectl in die Cloud geladen.

Wie man in obigem Diagramm sieht, wird dabei nur der https Port in der Firewall nach außen freigegeben, das REST-API ist hier hinter dem Reverse Proxy verborgen.

• bash
• docker
• quarkus
• JEE
• nodejs
• webpack
• maven
• git
• openapi
• kubernetes

Unsere Software hat vor allem auch die Aufgabe Daten zu erfassen und sicher zu speichern. Ein Beispiel: Wir möchten Online etwas einkaufen, durchstöbern das Angebot und stellen uns sehr zufrieden unseren umfangreichen Warenkorb zusammen.

Stellen wir uns einmal vor, wie wir uns fühlen würden, wenn dann beim Kaufabschluss plötzlich folgende Meldung erscheint: “Das Produkt XY, das sie bestellt haben, ist nicht mehr verfügbar. Ihr ganzer Warenkorb wurde deshalb gelöscht”.

Erfüllt diese Software das Prinzip der kleinsten Überraschung ? Würden wir noch einmal in diesem Shop eine umfangreiche Bestellung zusammenstellen?

Es ist erstaunlich, dass wir manchmal im Berufleben auch im dritten Jahrtausend A.D. noch mit solcher Software arbeiten müssen. Eine Anwendung, die sich so verhält, ist einfach fehlerhaft.

Wir erwarten uns von einer korrekten Software, dass uns ein Produkt, das wir nicht kaufen können, auch gar nicht zur Auswahl angeboten wird.

Dann sollten wir auch noch darüber nachdenken, ob Benutzer es mögen, wenn wir Daten vernichten, die sie bereits eingegeben haben …?

Manchmal müssen wir in unseren Anwendungen den Benutzer dabei unterstützen bestehende Daten zu kopieren. Allein dieser Umstand sollte uns zu denken geben, hierbei handelt es sich wahrscheinlich um einen Design-Fehler im Datenmodell.

Sollten wir aber dennoch zu der Entscheidung kommen dem Benutzer einen Dupliziervorgang anzubieten, müssen wir das auch richtig implementieren. Eine Kopie muss gleich dem Original sein. Das bedeutet, dass jedes einzelne Feld mit dem entsprechenden Feld im Original übereinstimmt. Die Kopie ist dann gleich dem Original. Die Kopie ist eine eigene Instanz, aber sie ist nicht dasselbe.

Wenn wir uns nicht daran halten, verletzen wir das Prinzip der kleinsten Überraschung. Wenn wir uns nicht daran halten ist dies kein Spezialfall - extra für unsere Anwendung die sich der Benutzer doch wohl wird merken können. Nein, es ist dann schlicht und einfach fehlerhafte Software.

Manche Programmiersprachen haben für dasselbe und das Gleiche sogar eine eigene Notation¹.

Gute Software zeichnet sich dadurch aus, dass sich die Benutzer im Umgang mit ihr wohlfühlen, dass wir damit eine angenehme Erfahrung erleben. Es ist angenehm, wenn wir unsere Anwendungen benutzen können ohne dabei in höchsten Maße konzentriert und gestreßt zu sein. Selbst ein Hochschulprofessor wird es schätzen, wenn er beim Ausfüllen seiner Reiserechnung nur sein halbes Gehirn einschalten muss.

Es ist höchst irritierend, wenn sich ein Programm anders verhält, als wir es im Alltag erwarten würden. Software soll die Benutzer unterstützen und nicht die Benutzer die Software.

Wenn wir Entscheidungen treffen, wie sich unsere Software in gewissen Situationen verhalten soll, ist das meist ganz einfach. Wir handeln nach dem Prinzip der kleinsten Überraschung. Unsere Anwendung muss so reagieren, wie es der Benutzer intuitiv erwartet und kein vollkommen überraschendes Verhalten zeigen. Dies verlangt von den Benutzern weniger Konzentration und belastet sie weniger. Unsere Anwendung steigt so in der Sympathie der Benutzer. Software soll sich idealer Weise so verhalten, wie wir es aus unserer täglichen Erfahrung mit der realen Welt gewohnt sind.

Manchmal macht es Sinn komplexe Objekte durch Attrappen zu ersetzen. Nach aussen hin sehen diese Attrappen aus wie die echten, schweren Objekte, tatsächlich sind sie aber leicht und einfach.

Sehen wir uns das am Beispiel des automatischen Testens einer Managed Bean in einer Jakarta™EE-Anwendung an. Wenn wir hier gegen eine echte Datenbank testen würden, wäre der Aufwand hoch. Jeder einzelne Testfall müsste sich in der Datenbank einloggen, Testdaten einfügen, seine Tests durchführen, dabei vielleicht umfangreiche Lese- und Schreibtransaktionen absetzen und am Ende diese Daten wieder entfernen. Abgesehen vom Verwaltungsaufwand würden diese Tests hohe Durchlaufzeiten haben, was wir nicht wollen. Der zusätzliche Wert, den die Verwendung der Datenbank an dieser Stelle bringt ist relativ gering. Trotzdem: Wir wollen unsere Anwendung testen ohne sie zu dazu verändern zu müssen. Wir wollen das Original testen.

Dazu verwenden wir für die Tests einen Platzhalter für das Objekt, das für uns die Datenbankzugriffe erledigt. Dieser Platzhalter implementiert dasselbe Interface wie unser echtes Datenbank-Zugriffsobjekt, aber seine Umsetzung gleicht der eines Potemkinschen Dorfes.

Um das zu veranschaulichen demonstrieren wir das jetzt an dem DataAccessObject für unseren RESTeasy und Wildfly Beitrag. Dazu erstellen wir statt einer realen Datenbank eine Klasse, die die Objekte im Speicher anlegt¹.

Das kann so aussehen:

@Named
@ApplicationScoped
public class InMemoryUserDatabase {
    private Map<Integer, User> users;
    private int sequence = 0;

    public InMemoryUserDatabase() {
        users = new HashMap<>();
        addUser("Joe Sixpack", "joe.sixpack@example.com");
        addUser("John Doe", "john.dow@example.com");
        addUser("Jane Roe", "jane.roe@example.com");
    }
    public User addUser(String name, String email) {
        User user = new User();
        user.id = ++sequence;
        user.name = name;
        user.email = email;
        users.put(user.id, user);
        return user;
    }
    public Map<Integer, User> getUsers() {
        return users;
    }
}

Hierbei haben wir der Datenbank den @ApplicationScope gegeben, so dass die Daten während der gesamten Laufzeit der Anwendung erhalten bleiben.

Damit implementieren wir unser UserDao:²

@Named
@RequestScoped
public class InMemoryUserDao implements DataAccessObject<User> {
    @Inject
    InMemoryUserDatabase userDatabase;

    @Override
    public User findById(int id) {
         return userDatabase.getUsers().get(id);
    }
    @Override
    public List<User> listAll() {
        List<User> sortedUsers = new ArrayList<User>(userDatabase.getUsers().values());

        Collections.sort(sortedUsers, new Comparator<User>() {
            public int compare(User lhs, User rhs) {
                return lhs.id - rhs.id;
            }
        });
        return sortedUsers;
    }
    @Override
    public User add(User user) {
        return userDatabase.addUser(user.name, user.email);
    }
    @Override
    public void delete(User user) {
        userDatabase.getUsers().remove(user.id);
    }
    @Override
    public boolean update(User user) {
        boolean ok = false;
        User existingUser = userDatabase.getUsers().get(user.id);
        if (existingUser != null) {
            existingUser.name = user.name;
            existingUser.email = user.email;
            ok = true;
        }
        return ok;
    }
}

Unser echtes UserDao würde zur Laufzeit einen EntityManager statt der InMemoryDatabase injiziert bekommen. Darauf geht das Tutorial über JPA genauer ein. User REST Service lässt sich damit aber schon fertig stellen.

Das alles klingt sehr verlockend. Die unverzichtbaren Voraussetzungen für das Verständnis dieser Beispielanwendung findet man in dem Beitrag Voraussetzungen. Ich empfehle dringend vorab diese Kenntnisse zu überprüfen, ansonsten macht die Beschäftigung mit dem Source Code wenig Sinn.

Den Source Code zum Beispiel finden Sie hier. Dabei handelt es sich um einen Typescript Client mit WebPack und einen Java/JPA/REST - Server mit Quarkus.

Bei jedem Push in den Master - Branch baut eine Github - Action das Projekt, erstellt die Docker-Images und lädt anschliessend diese Images in die Cloud. In meinem vorangegangenen Blog über Minikube finden sie, wie wir das Projekt vorher auf dem eigenen Rechner testen.

Man denke zum Beispiel an eine alltägliche Aufgabenstellung: Ein Benutzer fügt ein Produkt zum Warenkorb hinzu. Wie mühsam ist es da für manche Programmierer das Badge rechts oben, das anzeigt wie viele Produkte sich im Warenkorb befinden, zu aktualisieren. Eine Vielzahl spaghettiartig verflochtenter Komponenten kommuniziert miteinander oder reagiert auf Inputs(), erzeugt Outputs und so weiter. Das Angular - Anfänger - Tutorial hierzu ist so lange, dass man beim Lesen schon beinah einen Muskelkater vom vielen Herumscrollen bekommt.

Das ist alles viel zu kompliziert, es geht wesentlich einfacher wenn wir uns konsequent an unsere Entwurfsmuster halten.

Unsere Anwendungen müssen große Mengen von “Zustand” verarbeiten. Dieser Zustand setzt sich zusammen aus den Antworten, die wir von unserem Applikations-Server erhalten haben, aus gecachten und lokal erstellten Daten, aus aktiven Routen, aktuellem Zustand von Fortschrittsbalken, Seiten- und Tabauswahl-Informationen und vielem mehr.

Diesen Applikationszustand zu managen ist eine nicht zu unterschätzende Aufgabe. Ein typisches Beispiel eines solchen Vorganges ist: ein Model aktualisiert eine View, dann aktualisiert diese View das Model, diese aktualisiert wiederum eine andere View, das ein anderes Model aktualisiert, da wiederum zum Update einer anderen View führt. Dabei treten zusätzlich viele Ereignisse asynchron ein, wie etwa eine Benutzereingabe, eine asynchron eintreffende Antwort vom Server, ein Event über einen Websocket etc.

Weil wir die zwei an sich einfachen Dinge Veränderung und Asynchronizität vermischen, ist die Komplexität schwer zu handhaben. Unserem Verstand fällt es schwer mit der Kombination dieser beiden an sich harmlosen Tatsachen umzugehen. Es erinnert etwas an das Beispiel Mentos und Coke.

In meinem Demo - Beispiel wird im www-Ordner gezeigt, wie wir mit den zwei Herausforderungen Veränderung und Asynchronizität problemlos umgehen können.

• Controller: Etwas, das den Ist- Zustand mit dem Soll-Zustand vergleicht und den Ist-Zustand ändert, bis er dem Soll-Zustand entspricht.
• ReplicaSet: versucht immer eine stabile Menge von Pods am Laufen zu halten.
• Node: ein Computer
• Pod: Ein Gruppe von einem oder mehreren Containern mit gemeinsamem Speicher und Netzwerk-Resourcen und einer Spezifikation, wie diese Container laufen sollen.
• Deployment: stellt deklarative Updates für Pods und Replicasets zur Verfügung. Der Deployment Controller ändert den Status der Deployments, so dass dieser dem vorgegebenen Zustand des Deployments entspricht.
• Service: Ein abstrakter weg um eine Applikation, die auf einer Menge von Pods läuft, nach außen verfügbar zu machen.
• Ingress: ein Controller, der ständig nachsieht, ob es aktuell neue Services gibt, die - falls ja - auf einem öffentlichen Port in das Internet freigegeben werden.
• Container: Das Ergebnis, wenn ein Dockerfile mit docker build oder docker-compose up --build gebaut wird.

Zunächst installieren, starten und konifgurieren wir minikube.

minikube start
minikube addons list
minikube addons enable ingress
minikube addons enable dashboard

Jetzt speichern wir die folgenden Dateien in unserem k8s¹ Ordner.

meow-deployment.yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: meow
spec:
  replicas: 2
  selector:
    matchLabels:
      app: meow
  template:
    metadata:
      labels:
        app: meow
    spec:
      containers:
      - name: meow
        image: gcr.io/kubernetes-e2e-test-images/echoserver:2.1
        ports:
        - containerPort: 8080

meow-service.yaml:

apiVersion: v1
kind: Service
metadata:
  name: meow-svc
spec:
  ports:
  - port: 80
    targetPort: 8080
    protocol: TCP
    name: http
  selector:
    app: meow

ingress.yaml:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: meow-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  rules:
  - http:
      paths:
      - path: /meow
        pathType: Prefix
        backend:
          service:
            name: meow-svc
            port:
              number: 80

Anschließend spielen wir das auf unserem minikube ein:

kubectl apply -f meow-deployment.yaml 
kubectl apply -f meow-service.yaml
kubectl apply -f ingress.yaml
minikube dashboard

Danach starten wir kubectl um uns das meow-service auf einen Port auf unserem Rechner zu forwarden:

kubectl port-forward service/meow-svc 4000:80

Damit haben wir in unserem Minikube folgende Situation:

Die URL, die wir im Browser aufrufen ist folgende: http://localhost:4000

Jetzt sehen wir, dass wir einen von außen erreichbaren Dienst haben.

Ein etwas umfangreicheres Beispiel mit einem Applikations-Server finden Sie hier.

Wenn unsere Projekte so vorbereitet sind, dass sie in dieser Art problemlos auf minikube laufen, können wir diese in unsere eigene Cloud einspielen. Wie wir uns aus ein paar normalen Servern aus purem Metall eine echte eigene Cloud bauen, sehen wir in einem der nächsten Beiträge.

Installation von OSX unter Windows

Die OSX-Programmierung lässt sich auch in einer virtuellen Umgebung unter Linux ausführen. Wer auf seinem Computer Windows installiert hat, verkleinert einfach die Windows Partition und installiert ein Dual-Boot System¹ mit Linux.

Installation von OSX unter Linux

Zur Installation folgen wir den Anweisungen aus dem macOS-Simple-KVM Projekt.

Damit sind wir bereit zum nächsten Schritt iOS Anwendungen entwickeln.