ANDROID_HOME unter macOS setzen

Beim Kompilieren eines Android-Projektes kann es zu folgender Meldung kommen:

Caused by: java.lang.RuntimeException: SDK location not found. Define location with sdk.dir in the local.properties file or with an ANDROID_HOME environment variable.

Diese Meldung besagt dass das SDK nicht gefunden werden kann, da die Eigenschaft sdk.dir bzw. die Umgebungsvariable ANDROID_HOME nicht gesetzt ist. Unter macOS befinden sich die Android-SDKs im Library-Pfad des angemeldeten Nutzers:

/Users/seeseekey/Library/Android/sdk/sources

Der Nutzername, in diesem Beispiel seeseekey, muss natürlich durch den eigenen Nutzernamen ersetzt werden. Um diesen Pfad als Umgebungsvariable einzutragen muss das Terminal geöffnet werden und mittels cd in das Nutzerverzeichnis gewechselt werden. Anschließend wird die Datei .bash_profile angelegt bzw. geöffnet:

cd
nano .bash_profile

In diese Datei wird nun folgende Zeile eingetragen:

export ANDROID_HOME=/Users/seeseekey/Library/Android/sdk

Damit wird die Umgebungsvariable ANDROID_HOME automatisch bei der Anmeldung gesetzt und kann anschließend auch vom betreffenden Android-Projekt genutzt werden.

Probleme mit dem Update von Android Studio unter macOS

Bei einem Updateversuch von Android Studio erhielt ich unter macOS den Fehler:

Studio does not have write access to /private/… Please run it by a privileged user to update.

Den gleichen Fehler zeigte auch IntelliJ IDEA, was nicht weiter verwunderlich ist, immerhin basiert Android Studio auf IntelliJ IDEA.

Die Fehlermeldung beim Updateversuch

Die Ursache für das Problem liegt an einem macOS High Sierra eingeführten Feature namens App Translocation. In diesem Fall führte das dazu das die betreffende App in einem zufälligen Pfad gestartet wurde. Bei mir wurde das Problem dadurch verursacht, das ich nach einer Neuinstallation die Applikationen vom Backup händisch (ohne Finder) in den Ordner /Application schob. Nachdem ich die Anwendung mit dem Finder erneut in den Applications bzw. Programme-Ordner kopiert hatte, funktionierte die Update-Funktionalität wieder ohne Probleme.

Ausführbare jar-Datei mittels Maven generieren

Für bestimmte Java-Projekte ist es durchaus praktisch als Ergebnis eine jar-Datei inklusive der benötigten Abhängigkeiten zu generieren. So kann das Projekt in Form einer einzelnen Datei unkompliziert ausgeliefert werden. Mittels Maven lässt sich dies relativ einfach bewerkstelligen. Dabei wird eine Basis-POM (pom.xml) benötigt, in welcher das Plugin maven-assembly-plugin konfiguriert wird:

<plugin>
	<artifactId>maven-assembly-plugin</artifactId>
	<version>3.1.0</version>
	<configuration>
		<archive>
			<manifest>
				<mainClass>com.example.webservice.Webservice</mainClass>
			</manifest>
		</archive>
		<descriptorRefs>
			<descriptorRef>jar-with-dependencies</descriptorRef>
		</descriptorRefs>
	</configuration>
</plugin>

Soll nach erfolgter Entwicklung die jar-Datei mit den Abhängigkeiten erzeugt werden, muss das Kommando:

mvn clean compile assembly:single

genutzt werden. Damit das Ganze auch beim gewöhnlichen:

mvn package

funktioniert, muss die pom.xml angepasst werden. Dabei wird zur Plugin-Definition ein executions-Block hinzugefügt, welcher dafür sorgt das dass Ziel single auch während der Phase package ausgeführt wird. Die komplette pom.xml sieht dann wie folgt aus:

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>

    <groupId>com.example</groupId>
    <artifactId>webservice</artifactId>
    <version>1.0.0</version>

    <properties>
        <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
        <project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding>
    </properties>

    <dependencies>
        <dependency>
            <groupId>com.google.code.gson</groupId>
            <artifactId>gson</artifactId>
            <version>2.8.5</version>
        </dependency>
    </dependencies>

    <build>
        <plugins>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-compiler-plugin</artifactId>
                <version>3.7.0</version>
                <configuration>
                    <source>8</source>
                    <target>8</target>
                </configuration>
            </plugin>
            <plugin>
                <artifactId>maven-assembly-plugin</artifactId>
                <version>3.1.0</version>
                <configuration>
                    <archive>
                        <manifest>
                            <mainClass>com.example.webservice.Webservice</mainClass>
                        </manifest>
                    </archive>
                    <descriptorRefs>
                        <descriptorRef>jar-with-dependencies</descriptorRef>
                    </descriptorRefs>
                </configuration>
                <executions>
                    <execution>
                        <id>make-assembly</id>
                        <phase>package</phase>
                        <goals>
                            <goal>single</goal>
                        </goals>
                    </execution>
                </executions>
            </plugin>
        </plugins>
    </build>
</project>

Alle im dependencies-Block verwendeten Abhängigkeiten, werden somit in die jar-Datei übernommen.

Datenbank und Medienoptimierung unter WordPress

Im Laufe des Lebens einer WordPress-Installation kann sich dass eine oder andere Datenfragment ansammeln. So existieren Einträge in der Datenbank welche nicht mehr benötigt werden oder es befinden sich Medien in der Mediathek, welche von keinem Eintrag mehr verwendet werden. Um dieser Probleme Herr zu werden existieren eine Reihe von Plugins zur Bereinigung der Installation.

Die Übersicht des Media Cleaners

Das erste Plugin, der Media Cleaner, ermittelt welche Medien sich in der WordPress-eigenen Mediathek befinden, aber nicht mehr genutzt werden. Nicht mehr genutzte Medien können anschließend gelöscht werden. Die Medien sollten allerdings mit Bedacht gelöscht werden; so erkennt der Media Cleaner keine URLs, welche sich normal im Text (sprich ohne a-Tag oder ähnliches) befinden. Auch kann es passieren das Bilder die laut dem Plugin nicht genutzt sind, falsch in den Beiträgen referenziert werden. So kann durch Domainumzüge und ähnliches der falsche Pfad zum Medium in den Beiträgen stehen. Hier muss der entsprechende Beitrag korrigiert werden.

Ein weiterer Punkt, auf der Liste zur Optimierung, ist die Datenbank. So speichert WordPress z.B. zu jedem Artikel die Revisionen. Pro Artikel können da schon ein halbes Dutzend und mehr Revisionen zusammenkommen. Mit dem Plugin WP-Optimize kann die Datenbank entsprechend bereinigt werden. Neben den Revision, werden die Tabellen optimiert und verwaiste Fragmente ebenfalls entfernt.

Eine weitere Sache bei der Optimierung von WordPress ist die Überprüfung der Verlinkungen. Mit dem Plugin Broken Link Checker kann dies bewerkstelligt werden. Nach der Installation überprüft das Plugin die Links innerhalb der Installation als auch externe Linkziele und stellt diese entsprechend da.

Broken Link Checker
Preis: Kostenlos

Bevor solche Optimierungen an der WordPress-Installation vorgenommen werden, sollte ein Backup der Datenbank und des Dateisystems erstellt werden. So kann die Installation, im Falle eines Fehler oder einer übereifrigen Optimierung, wieder hergestellt werden.

REST-Service mittels Spring Boot aufsetzen

Sprint Boot vereinfacht das Setup eines Spring-Projektes und geht dabei nach der Methode Konvention vor Konfiguration vor. So lässt sich ein einfacher REST-Service mittels Spring Boot schnell und unkompliziert implementieren. Im ersten Schritt wird dazu mit dem Spring Initializr ein neues Projekt mit der Abhängigkeit Web angelegt.

Mit dem Spring Initializr wird ein Projekt mit der Abhängigkeit Web angelegt.

Nach dem Download des Projektes wird dieses in der IDE der Wahl (z.B. IntelliJ IDEA) geöffnet und eine Klasse mit dem Namen HelloWorldController angelegt. Die Klasse sollte im gleichen Package (in diesem Beispiel: com.example.demo) wie die DemoApplication angelegt werden und wie folgt aussehen:

package com.example.demo;

import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.PathVariable;
import org.springframework.web.bind.annotation.RequestParam;
import org.springframework.web.bind.annotation.RestController;

@RestController
public class HelloWorldController {

    @GetMapping("/hello")
    public String helloWorld(@RequestParam final String name) {
        return "Hello " + name + "!";
    }

    @GetMapping("/hello/{name}")
    public String helloWorld2(@PathVariable("name") final String name) {
        return "Hello " + name + "!";
    }
}

Über die Annotation @RestController wird dem Framework mitgeteilt das es sich bei dieser Klasse um einen Controller für die REST-API handelt. Anschließend wird die Ressource hello definiert. Diese kann über zwei Wege aufgerufen werden:

http://localhost:8080/hello?name=seeseekey
http://localhost:8080/hello/seeseekey

Bei beiden Aufrufen erscheint als Ergebnis der Text:

Hello seeseekey!

Der erste Aufruf wird auf die Methode helloWorld gemappt, während der zweite Aufruf mit dem Parameter in der URL an die Methode helloWorld2 gemappt wird. Mittels der Annotation @GetMapping wird der URL-Pfad festgelegt, auf welchen die Methode reagieren soll. Bei der ersten Methode kommt die Annotation @RequestParam zum Einsatz, welche einen gewöhnlich Parameter definiert, welcher von der eigentlichen URL abgetrennt ist. Dagegen wird mit der Annotation @PathVariable in der Methode helloWorld2 eine Variable im Pfad der eigentlichen URL definiert.