Bash, tee und $?: Der korrekte Umgang mit $?

Beim Ausführen von Unix-Scripten muss man oft auf den Rückgabecode $? von Anwendungen reagieren. Also fragt man diesen mit if ab.

Oft benötigt man dann noch ein Log von der Ausgabe des Kommandos. Also wird die Ausgabe umgelenkt in eine Datei. Möchte man diese Ausgabe dann auch noch sofort sehen, verwendet man den Befehl tee.

Und genau hier beginnt nun das Problem:

Wenn man mit $? den Returncode abfragt, erhält man nicht den Returncode des ausgeführten Programmes sondern den Returncode von tee!

Lösung:

Setzen der pipefail-Option im jeweiligen Shell-Skript

set -o pipefail

bevor die gewünschte Anwendung gestartet wird.

Quelle: Stackoverflow

Dinge mit eigenen Augen sehen ist was anderes, als Bilder zu sehen

Am 27.07.2018 abends war eine Mondfinsternis. Ich war etwas ratlos unterwegs, da ich nicht wusste, wo bzw. wann der Mond zu sehen ist.

Ich war nicht der einzige, der den Mond beobachten wollte. Ich Traf einen Amateur-Astronom, der mit einem recht grossen, transportablen Teleskop unterwegs war.

Leider hat sich der Mond erstmal hinter Wolken bzw. einem Berg versteckt.

Ich fragte, ob er wüsste, was für ein Stern an einer bestimmten Stelle am Himmel zu sehen sei. Das ist der Saturn, war die Antwort und er richtete das Teleskop auf diesen Punkt. Ich durfte dann durch das Teleskop auf diesen winzigen Lichtpunkt schauen. Ich konnte mit eigenen Augen den Saturn mit seinen Ringen durch das Teleskop sehen. Das hat mich sehr beeindruckt. Ich kenne viele Bilder vom Saturn – Cassini sei Dank – aber mit eigenen Augen die Ringe zu sehen hat mich vom Sockel gehauen.

Swagger 2.0

Swagger ist ein Opensource-Framework zur Unterstützung bei Design, Entwickelung, Test und Dokumentation von RESTful APIs.

Mit der Version 2.0 werden dazu die Module

  • Swagger Editor zum Design,
  • Swagger Build zum Generieren von Clients und Servern,
  • Swagger UI um Dokumentieren von Schnittstellen

angeboten.

Entwicklung der Service-Dokumentation mit swagger-editor

In meinem Fall lag das RESTful API auf Serverseite schon vor. Ich wollte dieses API für Konsumenten der Schnittstelle dokumentieren. Dazu bietet sich das Javascript-basierte Module swagger-editor an.  Die Installation erfolgt einfach:

Von github.io wird das Projekt https://github.com/swagger-api/swagger-editor heruntergeladen, anschließend werden die notwendigen rpm-module mittels

$> npm install

installiert. Durch Aufruf von

$> npm start

wird dann der webbasierte Editor aufgerufen.

Darin wird die Beschreibung des RESTful-API entweder in einer JSON-Struktur oder in der YAML-Schreibweise festgelegt. Die API-Definitionen können dort interaktiv getestet werden – einfach großartig, wie schnell man dort einen Überblick über sein API bekommt.

Ist die Definition der Schnittstelle – hier einen Clients – abgeschlossen, wird diese als JSON- oder als YAML-Datei auf einem Web-Server bereitgestellt.

Bereitstellen der Service-Dokumentation in Swagger-UI

swagger-editor ist ein Editor zum Entwickeln der Service-Beschreibung. Diese Modul ist nicht geeignet, um den eigenen Service für andere zu dokumentieren – in diesem Fall sollte die Service-Schnittstelle nicht mehr veränderbar sein.

Genau diese Zweck erfüllt das Modul swagger-ui, welches man ebenfalls von github.io herunterladen kann.

Hat man dieses Modul heruntergeladen, so muss man noch den Verweis auf die zu testenden Schnittstelle eintragen.

Dazu ändert man in dist/index.html den Verweis auf die weiter ob bereitgestellte eigene swagger.json -Datei.

Anschliessend lädt man den ganzen swagger-ui-Ordner auf den gewünschten Web-Server.

Repeatable Migrations mit Flyway 4.0

Flyway ist ein Datenmigrations-Tool und stellt mit der neuen Version 4.0 die „repeatable Migrations“, also wiederholbare Migrationen vor.

Wiederholbare Migrationen sind z.B. Definitionen von Views, Prozeduren, Funktionen und Packages, die, auch wenn sie sich verändern, nicht als Differenzskript, sondern als komplette Definition in die Datenbank eingespielt werden. Vor allem aber ist es so möglich, unter Beibehaltung des Dateinamens mehrere Versionen der Datei mittels Flyway in die Datenbank einzuspielen.

Anwendungsbeispiel

im Schema hr liefert die view Managers eine Sicht auf alle Mitarbeiter, die als Manager tätig sind.

Diese View ist in der Datei R1__View_Manager.sql definiert.

create view manager as select id,name from employees

Nun wird die Tabelle employees um eine Spalte isManager erweitert. Das Skript dazu steht in V1.1__manager_add_isManager.sql

alter table employees add isManager char(1) default 'N';

Entsprechend muss sich die View-Definition ändern. Diese Änderung erfolgt in der Datei R1__View_Manager.sql:

create or replace view Manager as select * from employees where isManager = 'Y'

Es ist dieselbe Datei wie die ursprüngliche Definition. Auf diese Weise lassen sich Änderungen an der Datei z.B. in GIT gut nachverfolgen und der Entwickler ist nicht mehr gezwungen eine weitere Datei mit der neuen Definition der View anzulegen. Das ist eine echte Verbesserung bei der Wartung und Entwicklung datenbankseitiger Logik.