Kategorie: Allgemein

GIMP Beautify

Nur für GIMP 2.8 und leider nicht mehr weiterentwickelt: Die Filter-Suite “Beautify”. Leider erhöhter Schwierigkeitsgrad, man muss sie selbst kompilieren. Unter Linux geht das so:

sudo apt-get install libgimp2.0-dev
git clone https://github.com/hejiann/beautify
cd beautify
make
make userinstall

Dann noch die Texturen runterladen und in den richtigen Ordner entpacken (steht in der Wiki des Projekts). Die Filter sind dann zu finden unter Filter/Beautify.

Die Belohnung: Mit wenigen Klicks werden aus Fotos coole Hingucker. Free&Open source.

Buchtipp: “Weniger schlecht über IT schreiben”

Bei O’Reilly ist ein Buch erschienen, das ziemlich viele Leute unbedingt lesen sollten. “Weniger schlecht über IT schreiben” von Christina Czeschik und Matthias Lindhorst erklärt auf über 200 Seiten, wie man es hinbekommt, dass Dokumentationen, Bücher oder Fachartikel (um nur einige Beispiele zu nennen) besser beim Leser ankommen. Denn darum geht es letztlich: Texte werden geschrieben, um gelesen zu werden, also ist es der Job des Autors, gefälligst dafür zu sorgen, dass dies gut funktioniert.

Ich bin in meiner IT-Karriere wahrlich schon auf eine Menge abschreckender Beispiele gestoßen. Letztlich bedeuten schlecht verständliche oder langweilige Dokumentationen etc. für Firmen einen messbaren Verlust an Produktivität und damit Geld. Wäre es nicht gut, das zu vermeiden? Das Autorenduo bemüht sich redlich, wichtige Tipps zu geben: Was macht einen Text verständlich, welche Metaphern funktionieren und welche nicht, wie erreicht man Aufmerksamkeit, wie überarbeitet man, wie arbeitet man produktiv? Übungen an den Enden der Kapitel machen aus dem Buch eine richtige Schreibschule für IT’ler.

Jeder, der in der IT tätig ist und öfter als selten Texte darüber zu verfassen hat (und sei es einer wie dieser), sollte einen Blick auf dieses Buch werfen.

Infos und Bestellmöglichkeit beim Verlag

DeltaCam auf F-Droid

Nach und nach bringe ich einige meiner Open Source-Apps bei F-Droid.org online. Den Anfang macht die DeltaCam, die Bewegungen im Bild festhält. So hinterlassen laufende Ameisen schwarze Spuren auf dem Foto.

Es ist wirklich nicht ganz trivial, eine App bei F-Droid online zu bringen. Deshalb wird es in der nächsten (8.) Auflage von Android Apps entwickeln für Einsteiger ein eigenes Kapitel mit einer Schritt-für-Schritt-Anleitung geben.

Als nächstes soll der “Malkasten für Kids” erscheinen. Wird aber noch ein paar Tage dauern.

Ach ja: F-Droid kann man als zusätzliche Shop-App installieren. Alle angebotenen Apps sind kostenlos und (soweit ich weiß) werbefrei. Eine Wohltat! Und somit die einzige echte Alternative zu Google Play, zumindest für einfache Apps wie Notizblock, Karten, Dateimanager, Mail, Multimedia, Cryptowährungen, Cloud-Synchronisation.

Buch-Updates

Vor ein paar Tagen habe ich mit den Arbeiten an der 8. Auflage von “Android Apps entwickeln für Einsteiger” begonnen. Da diesmal (glücklicherweise) kein hypernagelneues Update von Android Studio meine Zeit raubt, weil ich tausend neue Screenshots erstellen muss, kann ich mich voll und ganz auf die Erweiterung und technische Aktualisierung kümmern. So wird endlich das neue Genehmigungs-Modell von Android 6 behandelt, aber in erster Linie erfährt das Kapitel “Tipps&Tricks” eine Erweiterung. Ich erkläre ausführlich das Senden und Empfangen (Android-Sprache: “Teilen”) von Daten zwischen Apps mit Intents, und in dem Zusammenhang auch das wenig bekannte Storage Access Framework mit seinem “Speichern unter”-Dialog, der es erlaubt, ohne Permission (mit Einverständnis des Nutzers) auf die SD-Karte zu schreiben. Außerdem erkläre ich eine Objektdatenbank zum extrem einfachen Verwalten von Daten. Gewählt habe ich dafür als Beispiel “Paper”. Ebenfalls neu wird ein Abschnitt über das Verwenden von REST- bzw. JSON-Webservices sein.

Derweil liegen die Verhandlungen über mein nächstes Fachbuch in den letzten Zügen. Offiziell verraten kann ich dazu noch nichts, nur so viel: Ich freue mich wahnsinnig darauf, das Frühjahr damit zu verbringen, ein Buch zu schreiben, von dem ich nie gedacht hätte, dass ich es je schreiben würde.

Meine schreiberischen Aktivitäten im SF-Bereich leiden naturgemäß darunter. Ich habe zwar ein neues Romanprojekt angefangen, aber es wird wohl kaum 2019 erscheinen. Nicht nur, weil ich nicht einmal einen Verlag dafür habe (nun, es wird sich hoffentlich einer finden), sondern auch, weil es ein etwas größeres Projekt wird. Ja, richtig gelesen: Der Post schreibt mal ein etwas dickeres Buch! Unglaublich aber wahr.

Mein letzter Roman, “Für immer 8 Bit”, hat übrigens vermutlich schon zwei Monate nach Erscheinen den vorletzten, “Walpar Tonnraffir und die Ursuppe mit extra Chili”, überholt, was die Verkaufszahlen angeht. Was mir das sagt? Dass ich die SF lieber anderen Kollegen überlassen soll? Oder dass es sich viel mehr lohnt, SF-Filme zu machen, weil man da zehnmal so viele Leute erreicht? Okay. Deshalb gehen natürlich auch die Arbeiten an unserem neuen Übermorgen Film weiter. Aktuell gibt es dazu ein Posting auf Patreon, das ein Video über die Entstehung des Ersten Offiziers bereithält. Viel Spaß damit!

 

Spring Boot-Anwendungen starten

Ohne viel Mühe lassen sich mit Spring Boot Web-Applikationen bauen. Sicher wissen Sie  schon, wie das funktioniert, wie cool das ist, und überhaupt und so. Aber wie starten Sie eine solche Anwendung? Mit dem normalerweise eingebetteten Tomcat-Application Server genügt es, mit java –jar oder, falls Maven vorhanden ist, mvn springBoot:run einzutippen. Aber auf einem Server genügt das nicht: Dort soll die Anwendung gefälligst automatisch starten. Dafür wurden unter Linux die init.d-Dienste erfunden. Spring Boot bringt dafür praktische Funktionen mit.

Nicht jede Spring Boot-Anwendung ist eine Webapplikation. Auch für Kommandozeilen-Programme eignet sich das Framework. Indem man eine Bean das Interface CommandLineRunner implementieren lässt, kann man eine solche Anwendung bauen. Die methode run(String… args) nimmt dabei eventuelle Parameter entgegen, und eine SimpleCommandLinePropertySource erlaubt es, sie auszuwerten. Das erzeugte Artefakt ist natürlich ein jar, das mit java –jar myapp.jar gestartet werden kann. Oder (unter Linux) auch direkt mit ./myapp.jar, wenn man das im Build vermerkt:

<plugin>

<groupId>org.springframework.boot</groupId>

<artifactId>spring-boot-maven-plugin</artifactId>

<configuration>

<executable>true</executable>

</configuration>

</plugin>

(Hier mit Maven)

Zu beachten ist, dass das Arbeitsverzeichnis der Anwendung dasjenige ist, in dem das jar liegt, und nicht etwa das, in dem der Startbefehl abgesetzt wurde. Wenn Sie beispielsweise vom Projektverzeichnis aus ein jar starten, das in target liegt, ist das ein wichtiger Unterschied.

Ist das jar auf diese Weise ausführbar gemacht worden, fungiert es automatisch auch als init.d-Service. Erzeugen Sie einfach einen symbolischen Link in /etc/init.d:

sudo ln –s /path/to/my/app.jar /etc/init.d/app

Hernach können Sie die App wie folgt verwalten:

/etc/init.d/app start

/etc/init.d/app stop

/etc/init.d/app restart

/etc/init.d/app status

Natürlich funktioniert auch der service-Befehl auf einem Debian-System:

sudo service app start

Mit den üblichen Mitteln kann die app dann zum Autostart-Mechanismus hinzugefügt werden:

sudo update-rc.d app defaults

Aber Vorsicht! Die Anwendung wird mit den Rechten des Users gestartet, dem die jar-Datei gehört. Dies sollte keinesfalls root sein, sondern ein User, der nur mit den notwendigen Rechten ausgestattet ist. Verwenden Sie einfach chown, um den Besitzer der Datei festzulegen.

Das von Spring Boot intern verwendete Start-Skript schreibt log-Meldungen nach /var/log/app.log, bis Ihr eigenes Logging-System aktiv wird. Für den Fall, dass beim Start etwas schiefgeht, müssen Sie also in /var/log/ nachschauen.

Wenn Sie statt System V das neuere systemd verwenden möchten, habe ich eine gute und eine schlechte Nachricht: Die gute ist, dass es natürlich funktioniert, die schlechte, dass es ein ganz klein wenig umständlicher ist, weswegen ich es an dieser Stelle nicht erkläre. Sie finden alles in der offiziellen Dokumentation: https://docs.spring.io/spring-boot/docs/current/reference/html/deployment-install.html

Tschüss, Cobertura

In meinem aktuellen Buch “Besser coden” zähle ich unter anderem Cobertura als Tools zum Ermitteln der Testabdeckung auf.

Gewohnheitsmäßig griff ich heuer auch in einem neuen Projekt zu Cobertura – und fand einen neuen Grund, über Softwarequalität zu schimpfen.

Gut, das ist jetzt ein bisschen unfair, denn die Entwickler von Cobertura sind nur halb schuld. Worin das Problem besteht?

Sobald ich Java-8-Syntax benutze, zum Beispiel eine Funktionsreferenz, wirft Cobertura eine ParseException. Es stellte sich heraus, dass der verwendete Java-Parser in JavaNCSS das nicht unterstützt – und auch nicht mehr weiterentwickelt wird (letztes Commit bei Github 2014, derzeit erschütternde 0 Contributors). Tatsächlich ist dieses Problem schon lange bekannt: Das zugehörige Issue wurde bereits im Juli 2014 eröffnet. In fast dreieinhalb Jahren hat es das Team von Cobertura nicht geschafft, das Problem zu beheben, etwa durch Migrieren zu einem anderen Parser.

Wir als Java-8-Entwickler, die längliche Stacktraces in Buildvorgängen eklig finden, ziehen die Konsequenz und wechseln das Tool.  Wie wär’s zum Beispiel mit OpenClover? Das ist die aktuelle Version des seit Juni 2017 geopensourceten Tools Clover von Atlassian. Eine Firma, die nicht gerade dafür bekannt ist, Schrott zu produzieren.

OpenClover lässt sich leicht in ein Maven-Projekt einklinken:

<build>
 <plugins>
  <plugin>
   <groupId>org.openclover</groupId>
   <artifactId>clover-maven-plugin</artifactId>
   <version>4.2.1</version>
  </plugin>
  ...
 </plugins>
</build>

Dann einfach wie folgt aufrufen:

mvn clover:instrument clover:check clover:clover

(Oder auch ins Maven-Reporting per mvn site einklinken, wie das geht steht hier)

Clover produziert damit eine hübsche, interaktive Webseite im Verzeichnis target/site/clover:

Abgesehen von der Testabdeckung erfasst OpenClover auch die Komplexität von Funktionen und die Ergebnisse von Unit-Tests und nimmt so ein paar anderen Tools die Arbeit ab.

OpenClover lässt sich leicht beibringen, bestimmten Code zu ignorieren, etwa Model-Klassen:

<configuration>
 <excludes>
  <exclude>**/model/*.java</exclude>
 </excludes>
</configuration>

 Außerdem können wir eine Mindestanforderung an die Testabdeckung einstellen: 

<configuration>
 <targetPercentage>50%</targetPercentage>
</configuration>

Stellt Clover einen zu niedrigen Wert fest, erzeugt es einen Build-Fehler. Bindet man diesen Vorgang in Mavens deploy-Phase ein, werden Artefakte mit zu geringer Testabdeckung eiskalt am Zutritt zum Repository gehindert.

Ein Eclipse-Plugin gibt’s auch (nicht über den Marketplace, sondern per Updatesite). Das Plugin zeigt ebenfalls ausführliche Statistiken und hinterlegt außerdem Codezeilen grün oder rot, je nachdem, ob sie von Tests durchlaufen wurden.

OpenClover steht unter Apache-Lizenz, so dass der Benutzung auch in dieser Hinsicht nichts im Wege steht.

 

Teilt eure Erfahrungen mit OpenClover! Ich bin gespannt, was ihr davon haltet.