AssertJ und java.util.List

AssertJ hat eine praktische Möglichkeit, Listen in JUnit Tests abzuprüfen. Insbesondere, wenn in der Liste komplexe Objekte abgelegt sind, spielt es seine Stärke aus. Über die Methode #extracting(...) werden die Eigenschaften angegeben, die aus dem Objekt per getter ausgelesen werden sollen. Die ausgelesenen Eigenschaften werden über #tuple(...) miteinander verglichen. Das ist dann praktisch, wenn nicht, wie in diesem Beispiel, die Objekte als Instanzen zur Verfügung stehen.

import static org.assertj.core.api.Assertions.assertThat;
import static org.assertj.core.api.Assertions.tuple;

import java.util.List;

import org.junit.jupiter.api.Test;

/**
 * Some examples to test a list.
 * 
 * @author Andre Winkler
 */
class ListAssert {

    @Test
    public void assertJdemo() {
        final Person a = Person.of("Winkler", "Andre");
        final Person b = Person.of("Winkler", "Adam");
        final Person c = Person.of("Winkler", "Lars");
        final Person d = Person.of("Winkler", "Erwin");

        final List list = List.of(a, b, c, d);

        assertThat(list).extracting("name", "firstName")
                .contains(
                        tuple("Winkler", "Andre"),
                        tuple("Winkler", "Adam"),
                        tuple("Winkler", "Lars"),
                        tuple("Winkler", "Erwin"));
    }

    private static class Person {
        private final String name;
        private final String firstName;

        private Person(String name, String firstName) {
            this.name = name;
            this.firstName = firstName;
        }

        public static Person of(String name, String firstName) {
            return new Person(name, firstName);
        }
        
        public String getName() {
            return name;
        }
        
        public String getFirstName() {
            return firstName;
        }
    }

}

Links

• AssertJ auf GitHub

Java Preview Features aktivieren

Einmal die neuen Textblöcke in Java 13/14 ausprobieren? Oder vielleicht das Switch-Case mit Strings? Einfach das neue JDK runterladen, auspacken, Pfade setzen und den richtigen Schalter bei der Compilierung einschalten!

Hier die Anleitung für Eclipse und Maven. IntelliJ erkennt anhand der pom.xml (Maven) wie zu Verfahren ist.

Eclipse

Package-Explorer öffnen, Projekt anwählen, rechts-klick, Properties auswählen oder Package-Explorer öffnen, Projekt anwählen und Alt-Enter drücken. Den Eintrag 'Java Compiler' auswählen, 'Enable project specific settings' einschalten und dann den Eintrag 'Enable preview features for Java X' aktivieren.

Maven

Mit Einsatz von Maven wird der Compiler-Schalter per Konfiguration in der pom.xml eingeschaltet:

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-compiler-plugin</artifactId>
    <version>3.8.0</version>
    <configuration>
        <compilerArgs>--enable-preview</compilerArgs>
        <encoding>UTF-8</encoding>
        <source>14</source>
        <target>14</target>
    </configuration>
</plugin>

Links

Java Example Project on GitHub

VI Tastenkürzel

Die Tastensteuerung im VI kann ich mir nur grob granular merken. Deswegen dieser Versuch, die Sachen einmal aufzuschreiben und natürlich nebenbei anzuwenden. Wer eine richtige Anleitung für den VI sucht, sollte lieber woanders schauen. Dort wird vielleicht auch die Philosophie vom VI erklärt.

Grundbefehle

Die Cursorsteuerung haben meine Finger angenommen. Trotzdem zur Erinnerung:

• j runter
• k rauf
• l rechts
• h links

Um in den Insert-Modus zu wechseln, drücke ich i. Mit ESC kann ich diesen wieder verlassen. :w schreibt die Datei und mit :q verlasse ich den VI. Das Kommando 'schreiben und verlassen' lässt sich auch zusammen fassen mit :wq.

Ok. Soweit sind mir die Dinge geläufig.

Fortgeschrittene Navigation

• ^ Cursor auf das erste Zeichen der Zeile. Unter Windows mit Cygwin muss ich die Taste zweimal drücken.
• $ Cursor auf das letzte Zeichen der Zeile.
• G oder :$ An das Dateiende springen.

Seitenweise Navigation

• <ctrl>d Halbe Seite nach unten springen.
• <ctrl>u Halble Seite nach oben springen.
• H M L Zum Kopf, Mitte oder Ende der Seite springen.
• w Wort nach rechts springen.
• W Cursor auf das Leerzeichen vor dem nächsten Wort.
• b Wort nach links springen.
• B Cursor auf das Leerzeichen vor vorherigen Wort.

Zeile löschen

dd oder mit einer Zahl voran gestellt 4dd werden 4 Zeilen gelöscht. Gelöschte Zeilen werden zwischen gespeichert und können mit p wieder eingefügt werden.

Suchen

/<Suchbegriff> Sucht nach dem ersten auftreten des Suchbegriffs. Falls der Suchbegriff gefunden wird, positioniert VI den Cursor an diese Stelle.

Suchen und ersetzen

:%s/<Suchbegriff>/<Ersetzung>/g

TODO: Ergänzungen folgen…?!?

ZSH aktualisieren unter cygwin

DISCLAIMER: Das ist kein ZSH Problem. Um es mal vorweg zu nehmen, der Schuldige sitzt, wie in vielen anderen Fällen, vor dem Monitor.

Was ist ZSH: ZSH ist eine Sammlung von Aliasen und hilfreichen Bash-Shell Skripten zur Verwendung unter Linux. Auf meinem Windows Rechner verwende ich cygwin, um so ein wenig der schönen Linux Welt auf meinem Rechner zu haben.

Vor cygwin 1.7.9 war es möglich, cygwin so zu konfigurieren, dass CRLF Dateien verarbeitet werden können. Diese Option gibt es in den aktuellen Versionen nicht mehr.

GIT lasse ich per cygwin installieren. Und war auch schon da, als ich mich entschied, ZSH zu installieren. Damals habe ich den Schalter core.autocrlf auf true gestellt. Warum? Das erschien mir praktisch…

Cygwin und Linux erwarten ein einfaches LF (LineFeed), während DOS/Windows auf CRLF (Carriage Return und LineFeed) setzt. Das ist vor allem dann problematisch, da der Shell-Interpreter CRLF nicht mag. Die bekannten Texteditoren können mit diesem Problem heute wunderbar umgehen.

Und jetzt das Drama: Nach der ersten Aktualisierung von ZSH waren ein oder zwei Dateien nicht mehr ausführbar. Was habe ich getan? Ich habe die Dateien mit einem Editor geöffnet und das richtige Linefeed eingetragen. Da die ganzen ZSH Dateien in einem GIT Repository liegen, die Änderungen im Anschluss commited. Mit der nächsten ZSH Aktualisierung kam es zu den gleichen Problemen. Zusätzlich hatte ich einige Merge-Konflikte. Und irgendwann habe ich mich auf die Suche nach einer Lösung begeben.

Diese lautet:

git config --global autocrlf false

Und das ist auch die Default-Einstellung, wenn man GIT installiert.

Allerdings gibt es unter Windows noch zwei weitere GIT Konfigurationen, die Einfluß nehmen können:

git config --global --edit
git config --system --edit
git config --local --edit

Letzters funktioniert nur in einem lokalen GIT Repository.

Mit git config --global -l kann man sich alle Schalter anschauen.

Bevor ich auf diese einfache Lösung gekommen bin, habe ich verschiedene andere hilflose Versuche unternommen:

• Alle Änderungen aus dem Remote-Repository ungesehen übernehmen.

  git pull -s recursive -X theirs <remoterepo or other repo>

  Das verhindert aber nicht die autocrlf Konvertierung.

• Oder

  git pull -X theirs

• Oder falls die Dateien bereits in einem konfliktbehaftetem Zustand sind:

  git checkout --theirs path/to/file

• Ein SED Skript, um die autocrlf Konvertierung wieder rückgängig zu machen: (Entfernt alle \r aus einer Textdatei):

  sed -i 's/\r$//' script

Aber wie gesagt / TLDR: autocrlf = false.

Oder in das lokale ZSH-GIT Repository wechseln:

cd ~/.oh-my-zsh git config core.autocrlf false

Links

• Cygwin 1.7.9 and DOS Line Endings
• ZSH
• GIT

Jenkins mit Tomcat unter Ubuntu auf einem Raspi 3

Grundlage sind ein Rapsi 3 und ein Ubuntu Server Image. Die Paketauswahl erscheint mir dort größer. Außerdem erhält man ein 'echtes' Server OS.

Einloggen geht initial über ssh mit der Kombination ubuntu/ubuntu.

Als erstes ein Update fahren:

sudo apt-get update
sudo apt-get upgrade

Das kann eine Weile in Anspruch nehmen. Eventuell werden diese Befehle geblockt, da der Server bereits selbständig Updates zieht.

Im nächsten Schritt lege ich mir einen Benutzer 'tomcat' an. In einigen Tutorials wird empfohlen einen User ohne Login-Rechte angzulegen. Das ist unter Sicherheitsaspekten vermutlich sinnvoll. Ich finde es allerdings praktisch, wenn ich mich direkt unter dem User einloggen kann. Der Raspi läuft bei mir nur im lokalen Netz.

sudo adduser tomcat

Meine benötigten Tools installiere ich unter dem Verzeichnis /opt/devtools/. Dazu gibt es für jedes Tool ein separatest Unterverzeichnis.

sudo mkdir /opt/devtools
sudo mkdir /opt/devtools/java
sudo mkdir /opt/devtools/maven
sudo mkdir /opt/devtools/node
sudo mkdir /opt/devtools/groovy
sudo mkdir /opt/devtools/ant

Die Tools hole ich mir mittels wget. Also z.B.

cd /opt/devtools/maven
sudo wget http://mirror.netcologne.de/apache.org/maven/maven-3/3.6.3/binaries/apache-maven-3.6.3-bin.tar.gz

Im Anschluss entpacken

tar -xvf apache-maven-3.6.3-bin.tar.gz

und einen symbolischen Link anlegen, der auf die latest Version verweist.

sudo ln -s /opt/devtools/maven/apache-maven-3.6.3 /opt/devtools/maven/latest

Tools wie ein aktuelles JDK oder NodeJS installiert man sich am besten über die Paketverwaltung von Ubuntu. In dieser findet man aktuelle Versionen des JDKs bzw. NodeJS. Im Raspian OS sind diese nicht auf dem neusten Stand.

Ein aktuellen Tomcat ziehe ich mir direkt aus dem Download Bereich des Jakarta Projekts. Also gleiches Spiel wie mit Maven. Im Anschluss vergebe ich die Benutzerrechte an Tomcat:

cd /opt/devtools/tomcat
sudo chown -R tomcat:tomcat /opt/devtools/tomcat

Für eine produktive Tomcat Instanz wären das zu weitgehende Rechte. Hier würde ich empfehlen, zumindest die Verzeichnisse bin, conf und lib auszuschließen, so das der Tomcat User nur auf die Verzeichnisse webapps, work, logs, temp schreibend zugreifen kann.

Damit der Tomcat bei einem Neustart automatisch mit hochgefahren wird, binden wir diesen als Systemd Service in das OS ein: sudo vi /etc/systemd/system/tomcat.service Und in die Datei landet dann der folgende Inhalt (Pfadangaben sind ggf. anzupassen).

[Unit]
Description=Apache Tomcat Web Application Container
After=network.target

[Service]
Type=forking

Environment=JAVA_HOME=/usr/lib/jvm/java-1.8.0-openjdk-amd64/jre
Environment=CATALINA_PID=/opt/devtools/tomcat/temp/tomcat.pid
Environment=CATALINA_HOME=/opt/devtools/tomcat/latest
Environment=CATALINA_BASE=/opt/devtools/tomcat/latest
Environment='CATALINA_OPTS=-Xms512M -Xmx1024M -server -XX:+UseParallelGC'
Environment='JAVA_OPTS=-Djava.awt.headless=true -Djava.security.egd=file:/dev/./urandom'

ExecStart=/opt/devtools/tomcat/latest/bin/startup.sh
ExecStop=/opt/devtools/tomcat/latest/bin/shutdown.sh

User=tomcat
Group=tomcat
UMask=0007
RestartSec=10
Restart=always

[Install]
WantedBy=multi-user.target

Im Anschluss den Daemon neu laden und den Tomcat starten, bzw. den Status abfragen.

sudo systemctl daemon-reload
sudo systemctl start tomcat
sudo systemctl status tomcat

Damit wäre die Basis angerichtet. Im nächsten Abschnitt deploye ich das Jenkins WAR. Aktuelle WARs finden sich auf der Jenkins Homepage. Und der Rest ist dann sehr einfach. Die WAR Datei wird in das webapps Verzeichnis vom Tomcat kopiert. Der Raspi braucht eine Weile, um die Anwendung zu starten. Nach einigen/vielen Minuten kann man die ersten Projekte anlegen. Das Initialpasswort findet sich unter:

sudo more /home/tomcat/.jenkins/secrets/initialAdminPassword

Man sollte von der Performance keine Wunder erwarten.