Philipps Blog

Um eine Play!-Anwendung zu testen, welche HTTP-Basic-Auth verlangt ist es notwendig, die Standard-Datei ApplicationTest.java anzupassen:
Verändert werden muss die Test-Methode testThatIndexPageWorks():

Aus

    @Test
    public void testThatIndexPageWorks() {
        Response response = GET("/");
        assertIsOk(response);
        assertContentType("text/html", response);
        assertCharset(play.Play.defaultWebEncoding, response);
    }

Wird:

    @Test
    public void testThatIndexPageWorks() {
        Request request = FunctionalTest.newRequest();
        request.user = "test";
        request.password = "test";
        request.url = "/";
        Response response = GET(request, "/");
        assertIsOk(response);
        assertContentType("text/html", response);
        assertCharset("utf-8", response);
    }

Wobei User = test und Passwort = test.
Bei allen weiteren Test-Methoden verfährt man analog, oder erstellt sich eine Factory-Methode für den Request.

Es ist möglich, eine Play!-Anwendung sehr einfach in eine WAR-Struktur zu übertragen und in einen Application-Server zu deployen.
Dies ist recht gut unter Deployment options in der Play!-Dokumentation recht gut erklärt. Was hier allerdings verschwiegen wird ist, wie man den notwendigen Context beim Routing konfiguriert. (Der Context ist der Pfad der Anwendung, welcher standardmäßig vom Namen des WAR-Archivs abgeleitet wird, oder per Descriptor konfiguriert wird) – heißt das Archiv testapp.war ist der Context /testapp.

Innerhalb einer Play!-App muss der Context sowohl in der Config Datei, als auch im Routing definiert werde:

application.conf

...
context=testapp
...

Danach lässt sich in der routes Datei der Context in die Routen konfigurieren:

# Routes
# This file defines all application routes (Higher priority routes first)
# ~~~~

%{ context = play.configuration.getProperty('context', '') }%

# Home page
GET     ${context}                                        Application.index
GET     ${context}/                                       Application.index

# Map static resources from the /app/public folder to the /public path
GET     ${context}/public/                                staticDir:public
GET     ${context}/Users/like/{uid}                       Users.like
GET     ${context}/Users/{uid}/show                       Users.show
...

Im Juli des letzten Jahres habe ich beim Chaos-BBQ in Dortmund einen Vortrag über Bitcoin gehalten.
Da ich heute darauf angesprochen worden bin, stelle ich die Slides hier online.

2011-07-10-Bitcoin

Vorwort

Hallo zusammen,

da ich in letzter Zeit von vielen Seiten nach Vorschlägen und Ideen für eine aktuelle Workstation gefragt werde, habe ich mir mal die Zeit genommen, um so ein System unter aktuellen Gegebenheiten zusammen zu stellen:

Das System soll folgende Anforderungen erfüllen:

1. Ausreichend Speicher und CPU, um eine oder mehrere Test-VMs neben den Entwicklungstools zu betreiben.
2. Es soll aktuelle Hardware verwendet werden, allerdings sollen die Ausgaben im vertretbaren Rahmen bleiben.
3. Das System sollte zukänftige Erweiterungen ermöglichen.

Anforderungen die das System nicht erfüllen soll:

1. Das System bietet keine interne Backupfunktion, d.h. es enthält keinerlei redundantes Raid, oder nutzt separate Backupplatten – dies lässt sich am besten über externe Laufwerke bewerkstelligen
2. Keine High-End Maschine, die mit größeren Servern miteifern möchte
3. Keine High-End Maschine, die mit High-End Gaming Systemen miteifern möchte

Mainboard

Bei dem Mainboard habe ich mich für das Intel® DH67GDB3. Unter anderem bietet es, neben der Unterstützung für die aktuelle Sandy Bridge Architektur, auch weitere Features wie:

• FW, SATA3, USB 3.0, eSATA
• max. 32GB Ram
• DVI, HDMI und Display-Port

Quelle: http://www.intel.com

Preis: ca. 100 EUR

CPU

Als CPU habe ich mich – passend zum Mainboard – für einen Intel® CoreTM i5-2500K “Sandy Bridge”. Diese CPU enthält, wie einiger der neueren Modelle, einen Grafikkern, sodass die Ausgänge des Mainboards vollständig unterstütz werden. Weiterhin bietet diese CPU 4 Kerne und alle aktuellen Intel-Befehlserweiterungen. Das ganze mit einem TDP von 95W. Weiterhin bietet diese CPU einen flexiblen Multiplikator. Damit lässt sich – rein theoretisch die Taktfreqzenz von 3.3 bis auf 3.7 GHz hochschrauben.

Quelle: http://www.intel.com

Preis: ca. 200 EUR

Arbeitsspeicher

Beim Arbeitsspeicher fiel die Wahl auf 16GB (4x4GB) – unspektakuläre, aber verlässliche – Bausteine von Kingston. Und zwar zweimal das Kingston ValueRAM DIMM 8 GB DDR3-1333 Kit.
Das dieses System kein ECC unterstützt, lässt sich das Geld hier beim Speicher sparen.

Preis: ca. 80 EUR

Grafikkarte

Die Grafikkarte ist hier optional, da CPU und Mainboard zusammen, eine ausreichend schnelle Darstellung bieten.

Festplatte

Aktuell sicherlich ein heikles Thema, da aufgrund des Hochwasser in Thailand die Festplattenpreise arg angestiegen sind. Das bringt uns in die seltsame Lage, dass SSDs aktuell in einem guten Preis-/Leistungs-Verhältnis zu Festplatten stehen. Ich würde für dieses System demnach eine Mischung aus schneller SSD und kleinerer HDD empfehlen. Meine Wahl fiel hier auf die Intel® 510 Series 2,5″ SSD 120 GB und die Western Digital WD3200AAKS 320 GB.

Quelle: http://www.wdc.com

Quelle: http://www.intel.com

Preis: ca. 230 EUR (SSD) und 100 EUR (HDD)

Laufwerke

Für die Installation von Software (bis die Nutzung von netboot.me soweit ist) und das Ausliefern von Software-Deployments bietet es sich immer noch an einen DVD-Brenner zu verbauen. Meine Wahl fiel hier auf das LG GH22LS70. Neben den gängigen Funktionen bietet das Laufwerk unter anderem auch Lightscribe, welches – bei geeigneten Medien – ein einfaches Beschriften ermöglicht.

Preis: ca. 25 EUR

Gehäuse

Ich habe mich bei der Auswahl der Komponenten an den alten “Pizzaschachteln” (z.B. alte Sun/SGI-Workstations) orientiert. Aktuell teilt sich die Masse an Systemen für Entwickler sowieso in Tower-Workstations oder Notebooks – von einigen hippen Buden, die iMacs nutzen mal abgesehen. War es bis vor wenigen Jahren noch einigermaßen schwierig ein Gehäuse dieser Bauart von der Stange zu bekommen, gibt es Dank des Trends hin zu HTPC Systemen (Wohnzimmer-Multimedia-Video-Systeme), einie eingermaßen große Auswahl.
Meine Wahl fiel hier auf das Lian Li PC-C37B, welches trotz der geringen Abmessungen ein normales ATX-Netzteil, sowie ein Standard Micro-ATX Mainboard aufnehmen kann. Weiterhin sind Steckkarten in halber Bauhöhe möglich.

Quelle: http://www.lian-li.com

Preis: ca. 100 EUR

Netzteil

Mit 530W ist das be quiet! Pure Power L7 530W für dieses System vollkommen ausreichend. Zudem belastet es die Umwelt nicht mit störenden Geräuschen und bietet eine stabile Stromversorung.

Quelle: http://www.be-quiet.net

Preis: ca. 60 EUR

Fazit

Für knapp 900 EUR bietet das System ausreichend Leistung – auch für anspruchsvolle Aufgaben. Durch den Kauf von größeren Festplatten, mehr Arbeitsspeicher und das Hinzufügen einer leistungsstarken Grafikkarte, bietet das System auch noch genug Raum für Erweiterungen. Im Preis nicht enthalten ist allerdings die notwendige Peripherie wie Tastatur und Maus, hier empfehle ich persönlich die Standardtastaturen von Cherry, daneben nutze ich schon seit Jahre eine einfache Logitech Kabelmause (MX 310).

Ein Wort zur Software

Ich bin seit einiger Zeit begeisterter Nutzer von Linux Mint. Diese Distribution verbindet die erfolgreichen Sourcen von Ubuntu (aktuell Ubuntu 11.10) mit einem einheitlichen und ansprechbarem Äußeren. Nett ist auch die gute Vorauswahl an installieren Programmen. So ist es zum Beispiel möglich, nach der Installation all seiner Anwendungen, sich ein DVD Image mit allen notwendigen Packages zu erstellen, um im Falle einer Neuinstallation schnell seinen alten Stand wieder zu erhalten.

Quelle: http://www.linuxmint.com

I just installed OpenIndiana with a ZFS Raid z1 on an old 1HE Rack Server. I was also able to make VirtualBox running . It looks like there will be some fun in the nearer future!

Nice to know:

The Build-In Security Realm of Jenkins/Hudson is based on acegisecurity. The Hash is Sha256 based. For a Salt

foo

and a password

bar

, you have to Hash

bar{foo}

, that’s then

77ce9123f864f6749a2b2c99b988089c21d33e39247f7b1276dfad01a112f038

(via hashgenerator.de)

You find the Hashes in <Jenkins-Dir>/users/<username>/config.xml

it is then storred as

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<user>
    <fullName>user</fullName>
    <properties>
        <jenkins.security.ApiTokenProperty>
            <apiToken>…</apiToken>
        </jenkins.security.ApiTokenProperty>
        <hudson.model.MyViewsProperty>
            <views>
                <hudson.model.AllView>
                    <owner reference="../../.."/>
                    <name>Alle</name>
                    <filterExecutors>false</filterExecutors>
                    <filterQueue>false</filterQueue>
                    <properties/>
                </hudson.model.AllView>
            </views>
        </hudson.model.MyViewsProperty>
        <hudson.security.HudsonPrivateSecurityRealm_-Details>
            <passwordHash>foo:77ce9123f864f6749a2b2c99b988089c21d33e39247f7b1276dfad01a112f038</passwordHash>
        </hudson.security.HudsonPrivateSecurityRealm_-Details>
        <hudson.tasks.Mailer_-UserProperty>
            <emailAddress>mail@example.com</emailAddress>
        </hudson.tasks.Mailer_-UserProperty>
    </properties>
</user>

Neben vielen berechtigten Kritikpunkten die manch einer dem Build-Tool Maven vorwerfen kann, ist oftmals der falsche Einsatz einer der Hauptgründe für die schlechte Perfomance (d.h. lange Build-Zeiten) die fehlerhafte Nutzung von Maven Features.

Oft sieht man, dass Module untereinander durch relative Pfadangaben verknüpft sind. Dies mag bei Ant-Builds ein gängiges Mittel sein, aber wenn man sich vor Augen hält, dass jeder Modul eines Projektes für sich genommen ausgecheckt und gebaut werden können soll, so ist klar, dass man eine abstractere Art und Weise benötigt, einzelne Module miteinander zu verbinden.

Und auch hierfür eignet sich das Mitte der Dependencies. Zu einem vollständigen (und nützlichem) Maven-Build-System gehört zwangsläufig auch ein (eigenes) funktionierendes Maven-Repository (sei es nun Archiva oder Nexus). So ein Repository dient nicht nur zum Lagern von Artefakten, sondern auch als Dreh- und Angelpunkt der einzelnen Module untereinander.

Nehmen wir an, ein Projekt besitzt folgende Struktur:

Root
  |-Modul A
  |-Modul B
    |-Modul C

Nehmen wir weiterhin an, dass Modul A von C abhängt, weil C zum Beispiel XSD Scripte enthält, die separat von einem Fachler aktualisiert werden, aber für die Generierung von Java-Klassen in A benötigt werden.

Würde es nach Ant-Manier gehen, so wäre folgendes denkbar:

<project>
...
    <build>
        <plugins>
            ...
            <plugin>
                <groupId>org.codehaus.mojo</groupId>
                <artifactId>xmlbeans-maven-plugin</artifactId>
                <version>2.3.3</version>
                <executions>
                    <execution>
                        <phase>generate-sources</phase>
                        <goals>
                            <goal>xmlbeans</goal>
                        </goals>
                    </execution>
                </executions>
                <inherited>true</inherited>
                <configuration>
                    ...
                    <schemaDirectory>../B/C/xsd</schemaDirectory>
                    <classGenerationDirectory>${project.build.directory}/classes</classGenerationDirectory>
                </configuration>
            </plugin>
            ...
        </plugins>
    </build>
...
</project>

Dies dürfte aber spätestens beim Release Build scheitern, weil hier jedes Modul für das Releas separat innerhalb des eigenen Target-Dirs ausgecheckt wird (spätestens hier kommt es dann mit den relativen Pfaden nicht mehr hin).

Was also tun?
Abhilfe schaft das maven-dependency-plugin, welches dem aktuellen Modul erlaub direkt auf die Daten eines einzelnen Artefacts zugreifen zu können. Damit das Artefact durch das Plugin verarbeitet werden kann, sollte es (logischerweise) auch als Dependency im eingetragen sein. So ist sogar sicher gestellt, dass immer der aktuellste Codestand verwendet wird, denn sollt ein Artefact im Repository neuere sein als das, welches lokal vorgehalten wird, so wird dieses heran gezogen.

Die obige Konfiguration würde sich also wie folgt ändern:

<project>
...
    <dependencies>
        ...
        <dependency>
            <groupId>com.example</groupId>
            <artifactId>C</artifactId>
            <version>${project.version}</version>
        </dependency>
        ...
    </dependencies>
    <build>
        <plugins>
            ...
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-dependency-plugin</artifactId>
                <version>2.3</version>
                <executions>
                    <execution>
                        <id>src-dependencies</id>
                        <phase>generate-sources</phase>
                        <goals>
                            <!-- use copy-dependencies instead if you don't want to explode the
                                sources -->
                            <goal>unpack</goal>
                        </goals>
                        <configuration>
                            <artifactItems>
                                <artifactItem>
                                    <groupId>com.example</groupId>
                                    <artifactId>C</artifactId>
                                    <version>${project.version}</version>
                                    <classifier>resources</classifier>
                                    <type>zip</type>
                                    <includes>**/*.xsd</includes>
                                    <overWrite>true</overWrite>
                                    <outputDirectory>${project.build.directory}/C</outputDirectory>
                                </artifactItem>
                            </artifactItems>
                        </configuration>
                    </execution>
                </executions>
            </plugin>            
            <plugin>
                <groupId>org.codehaus.mojo</groupId>
                <artifactId>xmlbeans-maven-plugin</artifactId>
                <version>2.3.3</version>
                <executions>
                    <execution>
                        <phase>generate-sources</phase>
                        <goals>
                            <goal>xmlbeans</goal>
                        </goals>
                    </execution>
                </executions>
                <inherited>true</inherited>
                <configuration>
                    ...
                    <schemaDirectory>${project.build.directory}/C/xsd</schemaDirectory>
                    <classGenerationDirectory>${project.build.directory}/classes</classGenerationDirectory>
                </configuration>
            </plugin>
            ...
        </plugins>
    </build>
...
</project>

Zu beachten ist hier, dass die Reihenfolge der beiden Plugins wichtig ist, weil ansonsten die Code-Generierung nicht auf die entpackten Dateien der Dependency zugreifen kann. Ich gebe zu, es handelt sich hier um ein einfaches Beispiel, aber zumindest der Drang, sich durch relative Pfade innerhalb von Maven-Files zu helfen ist meiner Beobachtung nach recht weit verbreitet :-/.

Manchmal gibt es den Fall, dass es notwendig ist, eine externe Bibliothek in einem Maven Projekt einzubinden. Um nun im Build Zyklus des Maven-Projektes keinen Bruch zu erhalten bietet es sich an, dass Artefakt manuell als Maven Artefakt im Repository zur Verfügung zu stellen.

Wir benutzen bei consolving.de u.a. ein öffentliches Maven Repository ( maven.javastream.de ) in dem wir einige OSS Artefakte den Entwicklern unter unseren Kunden zur Verfügung stellen. Hierbei handelt es sich nicht um ein vollständiges Repository System wie Archiva oder Nexus, sondern um ein lokales Repositry, welche statisch per Web-Server zur Verfügung stellt wird. Das ganze wird befüllt durch einen Jenkins-CI Server, der im Hintergrund alle Projekte periodisch neu dorthin deployed.

Es sind vier Schritte notwendig damit ein Deployment über SCP möglich ist:

1. Das Verzeichnis des Repositories muss per scp erreichbar sein – hierzu bietet es sich an, den SSH-Key auf dem Server zu hinterlegen.
2. Einrichten der notwendigen Credentials unter der ~/.m2/settings.xml

   <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
   <settings>
        <servers>
            <server>
                <id>maven.javastream.de</id>
                <username>##user##</username>
                <privateKey>##user##</privateKey>
            </server>
        </servers>
    </settings>

3. Vorbereiten des Third-Parts Projektes
   Ein vollständiges Maven-Artefakt besteht aus drei Teilen: 1. das Binary, 2. die Sourcen und 3. die JavaDoc Dateien. Alle drei Teile sollten als JAR gepackt werden.
   Nachfolgend ein Script, welches die drei notwendigen Teile in Archive packt:

   #!/bin/bash
   
   # Direkt aus dem Directory zu packen scheint die einzige Möglichkeit zu sein, dass die einzelnen Dateien direkt im Root des JARs liegen.
   cd src
   jar -c . > ../src.jar
   cd ..
   
   cd doc
   jar -c . > ../doc.jar
   cd .
   
   cd lib
   jar -c . > ../lib.jar
   cd .

4. Zuletzt werden nun die drei JARs per Maven-Command in das Repository geladen:

   #!/bin/bash
   
   #Binary
   mvn deploy:deploy-file -DgroupId=de.javastream \
     -DartifactId=example \
     -Dversion=1.0 \
     -Dpackaging=jar \
     -Dfile=lib.jar \
     -DrepositoryId=maven.javastream.de \
     -Durl=scp://maven.javastream.de/home/javastream.de/maven
   
   # Javadoc
   mvn deploy:deploy-file -DgroupId=de.javastream \
     -DartifactId=example \
     -Dversion=1.0 \
     -Dclassifier=javadoc \
     -Dpackaging=jar \
     -Dfile=doc.jar \
     -DrepositoryId=maven.javastream.de \
     -Durl=scp://maven.javastream.de/home/javastream.de/maven
   
   # Sourcen
   mvn deploy:deploy-file -DgroupId=de.javastream \
     -DartifactId=example \
     -Dversion=1.0 \
     -Dclassifier=sources \
     -Dpackaging=jar \
     -Dfile=src.jar \
     -DrepositoryId=maven.javastream.de \
     -Durl=scp://maven.javastream.de/home/javastream.de/maven

Im letzten Post wurde eine kurze Beschreibung in den Aufbau einer Play! Anwendung gegeben.
Nachfolgend soll eine einfache kleine Anwendung erstellt werden.

Die Anwendung soll die Links von verschiedenen Webseiten als Bookmarks speichern.
Hierzu benötigen wir ein Model für ein Bookmark:

package models;

import java.util.Date;
import javax.persistence.Entity;
import javax.persistence.Temporal;
import javax.persistence.TemporalType;
import play.data.validation.Required;
import play.db.jpa.Model;
@Entity
public class Bookmark extends Model {
    @Temporal(TemporalType.DATE)
    public Date createdAt;
    @Required
    public String title;
    @Required
    public String url;
    public Bookmark(){
        createdAt = new Date();
    }
}

Wie der geneigte Java-Entwickler auf den ersten Blick erkennen mag, handelt es sich um ein normales JPA Model. Einzig der public Accessor für die einzelnen Attribute erscheint befremdlich.
Zur Beruhigung sei gesagt, dass hier eine der Vereinfuchungen von Play! in Aktion tritt. Zur Laufzeit werden hier die notwendigen Getter/Setter erstellt (diese können aber auch selbst definiert werden), sowie der direkte Zugriff auf die Attribut verhindert. (vgl. http://www.playframework.org/documentation/1.2.3/model#properties ).

Weiterhin unbekannt ist hier die Anotation @Required. Play! unterstützt hier eine on-Model-Validation. Das Attribut wird als Required gekennzeichnet, es ist also notwendig, dass diese Attribut zu Persistierung gesetzt ist. Wie die Validierung im Controller verwendet wird, dazu später mehr.

Wie einige vielleicht ja schon wissen beschäftige ich mich jetzt schon seit einige Zeit mit dem recht neuen, aber mittlerweile immer bekannterem, Java-basiertem Web-Framework Play!. Anders als bei vielen neueren Frameworks wird nicht durch die Mittel einer dynamischen Sprache, sondern durch die Vereinfachung der bestehenden Sprachmittel von java versucht die Entwicklung einer Web-Anwendung zu beschleunigen und zu vereinfachen. Das bedeuten unter anderem das konsequente Weglassen der bisherigen Package-Struktur. Auf der anderen Seite werden altbewährte Bibliotheken aus der Java-Welt verwendet (z.B. JPA, Hibernate, Lucene, usw.). Da es eine ganze Menge an englischsprachigen Tutorials gibt und ich mir schon länger vorgenommen habe in einem kleinen Tutorial die grundlegenden Züge einer Play!-Anwendung zu beschreiben, wird dieser Text mal wieder in Deutsch sein .

Play verwendet – wie fast alle aktuellen Web-Frameworks ein MVC-Pattern,

So sollte es einem Entwickler (egal ob Ruby, Java oder Python), der mit der aktuellen Techniken vertraut ist, relativ leicht fallen, sich mit dem typischen Aufbaue einer Play-Anwendung zurecht zu finden.

Die Installation des Frameworks ist auf der Seite des Projektes gut erklärt. Neben einer aktuellen JVM sind keine weiteren Vorausetzungen zu erfüllen. Wichtig ist nur, dass das “play” Script im aktuellen Pfad erreichbar ist.

Nachfolgend möchte ich eine kleine Bookmark-Verwaltung erstellen.

Mit einem

# play new bookmarks

Wird die Grundstruktur einer Play-Anwendung erstellt.

Das oberste Verzeichnis enthält alle Modelle, Controller und Views der Anwendung (dazu später mehr). Unter “conf” befinden sich folgende Dateien:

- application.conf: Konfiguration der Anwendung – Art der DB, Caching, Konfiguration der Module
- dependencies.yml: Play unterstützt Module, die verschiedene Funktionen kapseln können. Seit Version 1.2 werden die Abhängigkeiten einer Anwendung durch Einträge in dieser Datei gesetzt.
- messages: Diese Datei wird für die Internationalisierung einer Anwendung benötigt (amerikanische Strings). Um eine neue Sprache hinzu zu fügen legt man eine neue Datei mit dem entsprechenden Ländercode an – z.B. messages.de für deutsch.
- routes: Play ermöglicht es, durch Einträge in dieser Datei, das Routing der Anwendung zu beeinflussen. Es erfolgt ein Mapping von URL auf Controller-Actions (dazu später mehr).

Das lib Verzeichnis kann verwendet werden um Java Libs zu verwenden, die nicht als Modul für Play! zur Verfügung stehen. Alle Jars im libs-Verzeichnis werden automatisch in den Classpath der Anwendung aufgenommen.

Das test Verzeichnis enthält die die Testdateien (Junit-/Selenium-Tests sowie ew. Fixures mit Testdaten).

Nach dem ersten Start der Anwendung werden noch zwei weitere Verzeichnisse erstellt:
Ein tmp-Verzeichnis (welches die kompilierten Klassen, sowie Caching Dateien enthält) und ein
db-Verzeichnis, welches bei der Wahl einer h2 Datenbank, die entsprechende Datenkbankdatei enthält (auch dazu später mehr).

Dies soll für die ersten 5 Minuten genügen .