nbsp; in XML

Im HTML existiert für das geschützte Leerzeichen die HTML-Entity:

nbsp;

Bei bestimmten Frameworks aus dem HTML5-Bereich wie Framework 7 kann diese Entity allerdings nicht genutzt werden, da z.B. Unterseiten als XML interpretiert werden und der Parser in diesem Fall mit einer Fehlermeldung reagieren würde. Stattdessen kann für das geschützte Leerzeichen das Zeichen:

 

genutzt werden. Bei diesem Zeichen handelt es sich ebenfalls um das geschützte Leerzeichen.

Domänenspezifische Sprache für Tests von REST-Schnittstellen

Eine domänenspezifische Sprache, kurz DSL, ist eine auf ein bestimmtes Problemfeld abgestimmte Sprache. Mit dem freien REST Assured existiert eine solche Sprache für den effektiven Test von REST-Schnittstellen. Genutzt wird REST Assured hauptsächlich unter Java und Groovy. Eine einfache Überprüfung des Statuscodes einer API-Anfrage würde in REST Assured wie folgt aussehen:

given().get("api.example.com").then().assertThat().statusCode(200);

Daneben sind auch komplexe Tests wie die Auswertung von zurückgegebenen JSON-Strukturen und Daten, sowie die Verknüpfung unterschiedlicher Bedingungen ohne Probleme zu implementieren. Eine große Übersicht über die Möglichkeiten von REST Assured bietet der Usage-Guide des Projektes.

rest-assured.io

Die Projektseite von REST Assured ist unter rest-assured.io zu finden. Der unter der Apache Lizenz (Version 2.0) lizenzierte Quellcode kann auf GitHub gefunden werden.

WADL-Dateien validieren

Bei WADL handelt es sich um die Web Application Description Language – eine Sprache mit der hauptsächlich REST-Services beschrieben werden. Auch wenn WADL in den letzten Jahren nicht mehr wirklich zum heißen Eisen gehört, wird es dennoch ab und an genutzt.

Ein WADL-Beispiel von Oracle.

Ein WADL-Beispiel von Oracle.

Möchte man eine solche WADL validieren, so kann man diese mit einem XML-Validator gegen das WADL-Schema validieren. Möglich ist dies z.B. mit folgendem Online-XML-Validator. Nachdem die zu überprüfende WADL im Validator eingetragen wurde, gibt man die URL:

https://www.w3.org/Submission/wadl/wadl.xsd

als Schema-URL an. Anschließend kann die XML-Datei gegen das XSD-Schema validiert werden.

SoundHelix

Musik per Algorithmus zu erzeugen klingt im ersten Moment abwegig, allerdings gibt es einige Personen und Projekte welche sich genau damit beschäftigen. Eines dieser Projekte ist dabei SoundHelix. Bei dieser in Java geschriebenen Anwendung handelt es sich um ein System mit welchem Musik algorithmisch erzeugt werden kann. Die erzeugte Musikstücke klingen dabei durchaus angenehm. Konfiguriert wird das System und deren Musik über eine XML-Datei.

soundhelix.com

soundhelix.com

Lizenziert ist SoundHelix unter der GPL und damit freie Software. Der Quelltext kann auf SourceForge bezogen werden. Zu finden ist das Projekt auf der offiziellen Seite unter soundhelix.com. Es ist dabei unter Linux, Mac OS X und Windows lauffähig.

Das TMX Format

Auf der Website http://www.mapeditor.org gibt es einen freien Tilebasierten Mapeditor names Tiled. Der Editor wurde in Java geschrieben und wird unter anderem von Projekten wie The Mana World (http://www.themanaworld.org) benutzt.

Das Standardformat dieses Editores ist TMX. Dabei handelt es sich um eine XML Datei in der die Daten kodiert sind. Vor einiger Zeit war ich damit beschäftigt einen Reader für das Format zu schreiben. Leider ist die Dokumentation des Formates sehr lückenhaft, aber dank einiger tatkräftiger Hilfe auf der Mailingliste war der Reader nach einer Weile dann doch fertig. Doch nun zum TMX Format. Eine TMX Datei könnte z.B. so aussehen: ow-testmap.tmx

Als erstes kommt der map Tag in dem alle anderen tags untergeordnet sind. Der erste Tag von Interesse ist dann der tileset Tag. In diesem Tag stehen der Name des Tilesets, die FirstGID (dazu später mehr), die Breite und Höhe der Tiles sowie das Quellbild des Tilesets.

Nachdem die Tilesets definiert sind beginnen auch schon die Layer Definitionen. Eine Karte kann aus mehreren Layern bestehen z.B. einem Kollisionlayer. Im Layer Tag stehen der Name, die Breite und Höhe des Layers. Darunter folgt bei komprimierten Karten (die Standardeinstellung von Tiled) der Tag data mit dem Attribut encoding. In unserem Beispiel ist die Kodierung Base64 und die Kompression gzip. Um an die Daten des Layers zu kommen muss man den von den Data Tags eingeschlossen String nehmen und mittels Base64 decodieren. Anschließend erhält man ein Byte Array. Dieses Byte Array muss dann noch mittels des gzip Algorithmus dekomprimiert werden. Bei dieser Aktion kommt am Ende auch wieder ein Byte Array heraus.

In diesem Byte Array stehen dann die Tilenummern drin und zwar in Form von 4 Byte Integers (Little Endian). Hat man z.B. eine 2×2 Karte so würden die Tiles in folgender Reihenfolge kommen: 0,0 – 0,1 – 1,0 – 1,1.

Nun stellt sich nur noch die Frage wie man diese Tilenummern interpretiert. Und dabei kommt jetzt die FirstGID des Tileset zum tragen. Nehmen wir an das wir die Tilenummer 270 auslesen. Um nun zu ermitteln zu welchem Tileset die Nummer gehört prüfen wir in welches Tileset in diesem Bereich liegt und stellen fest das das Tileset desert2 genau in diesem Bereich liegt. Dann rechnet man noch Tilesetnummer – FirstGID und schon hat man die Tilesetnummer und das Tileset (in diesem Fall 11). Nun wissen wir das das Tile das elfte Tile im Tileset desert2 ist.