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 Conext 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>

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

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 .

Wie einige ja vielleicht wissen, betreibe ich schon seit einiger Zeit ein NAS auf FreeNAS Basis.
Da mir die Verschlüsselung sehr wichtig war und ich bedingt anfangs schwache Speicherausstattung auf Nummer sicher gehen wollte, nutze ich hier aktuell ein FreeBSD Raid5 mit ELI Verschlüsselung.

Aber eigentlich bin ich ja schon immer ein großer FAN von ZFS gewesen. Da der Support von FreeNAS 7 ja scheinbar in absehbarer Zeit nicht mehr gesichert ist, habe ich mich gleich der aktuellsten Version “FreeNAS 8″ zugewandt.

Allerdings muss ich sagen, dass ich nach einigen ersten Tests in einer VirtualBox VM doch arg enttäuscht bin.
Natürlich ist nicht zu erwarten, dass die Mädels und Jungs von IX Systems (die sonst einen Prima Job machen), eine neue Version mit allen Features von 7.x raus bringen.
Aber zumindest das was sie dann als final Version 8 raus bringen sollte doch das tun, was es verspricht.

Aber zuerst einmal die positiven Aspekte:

The Good

1. Installation

Im Vergleich zu FreeNAS 7 ist die Installation von FreeNAS 8 in einem Bruchteil der Zeit durchführbar. Da in der offiziellen Empfehlung auch eine Installation auf einem USB Stick empfohlen wird, ist nicht damit zu rechnen, dass solche unschönen Bugs auftauchen, wie in der letzten Version (von 7.2) der Bug mit den Samba-Usern (SMB User müssen nach jedem Neustart per smbpasswd -a neu angelegt werden, da das System ein paar Einstellungen scheinbar “vergißt”).

2. Boot

Der Boot-Prozess wurde ebenfalls deutlich beschleunigt. Im Gegensatz zu den paar Minuten dauerndem Boot-Prozess von 7.2 ist das Booten von 8 in unter einer Minute durch.

3. UI

Das UI wirkt zumindest moderner als die Version 7.2. Es wird viel JS/CSS Foo geboten. Aber irgendwie haben es die Entwickler zu gut gemeint: an einigen Stellen gibt es deutliche Redundanzen in der Navigation – einige Verhaltensweisen des UIs sind in meinen Augen unlogisch. Was sehr schön ist, ist dass sich das UI die geöffneten Tabs merkt – und das überhaupt Tabs benutzt werden (ein Feature, was seit Firefox ja scheinbar zum Standard gehört ).

The Bad

Irgendwie habe ich das Gefühl, dass zumindest der Unix (FreeBSD?) Unterbau nur sehr schwach mit dem UI (Python/DOJO) verbunden ist. So gibt es über die Shell noch nicht mal einfache Tools wie FDISK. Zudem scheinen ZFS Pools, die über die Web UI angelegt wurden, über die CLI-Tools Zpool und ZFS unauffindbar zu sein.

Was mir persönlich auch fehlt ist die Möglichkeit, Log-Meldungen über das Web UI einzusehen. Scheinbar ist das auch noch so eine Baustelle die da offen ist .

Fazit

Zu guter Letzt lässt sich sagen, dass der Anfang schon sehr gut aussieht. Allerdings hat die Software noch so arge Fehler und Probleme, dass ich sie die nächsten paar Monate wohl nicht mehr anfassen werde. Das ich schon bei der einfachsten und essentiellen Funktion, nämlich dem Anlegen eines simplen RAIDZ Pools auf solche Probleme treffe, hätte ich eigentlich nicht erwartet. Mein Test-System bestand wirklich nur aus einer einfachen VM mit 1x4GB Boot Device und 4x2GB Data-Devices. Wieso es hierbei zu solchen Problemen kommt ist mir schleierhaft.

Die Nutzung von Dual-Boot Systemen (Linux/Windows oder Mac-OS/Windows) bietet sich manchmal an, um vielleicht neben der gängigen Arbeit auch noch mal ein Spiel zocken zu können.
Oder es ist einfach notwendig, eine VM auf einem mobilen Datenträge für die Nutzung auf unterschiedlichen Betriebssystemen zu verwenden.
Das einzige Dateisystem, welches auf allen aktuellen OS-Version ohne die Nutzung von irgendwelchen zusätzlichen Treibern für Schreib- und Lese-Zugriffe verwendet werden kann, ist immer noch FAT32.
Das Problem an der Sache ist nur, dass FAT32 Architektur-bedingt nur eine maximale Dateigröße von 2GB erlaubt.
Virtualbox nutzt standardmäßig das VDI Format, welches leider kein splitten der Image-Dateien erlaubt.

Allerdings fand ich auf der Seite von wischonline.de einen Post in dem erläutert wird, wie man mit dem CLI-Tool VBoxManage .vmdk Dateien erstellt werden können, welche sich in 2GB splitten lassen, aber ebenfalls auch mit Virtualbox nutzbar sind. Das .vmdk Format stammt ja eigentlich von VMWare, allerdingst unterstützt VirtualBox seit einigen Version auch dieses Format.

Als erstes sollte man dafür sorgen, dass VBoxManage im Pfad erreichbar ist (so das noch nicht der Fall ist). Unter Windows habe ich hierzu die Variabel VBOX_HOME auf C:\Program Files\Oracle\VirtualBox gesetzt und anschließend die Umgebungsvariabel PATH um %VBOX_HOME% erweitert (Trennzeichen ; nicht vergessen). Dieses Vorgehen erleichtern
ungemein die Lesbarkeit der PATH Variabel.
Um ein (mitwachsendes) Volume mit 64GB Größe zu erstellen, welche in 32 x 2GB Dateien gesplittet wird, reicht folgender Aufruf:

VBoxManage createhd --filename Win2k8-r2-disk1.vmdk --size 65536 --format vmdk --variant split2g

Anschließend reicht es aus, das neue Image in die vorhandene VM einzubinden und dann mit Imaging-Tools (z.b. gparted oder mit einem simplen DD) eine Copy der größeren Image-Datei durchzuführen. Hierbei sollte man immer stehts dran denken, das Boot-Flag auch in der neuen Partition mit zu setzen. Anschließen entfernt man das alte Image und bootet neu von dem neu erstellten VMDK Image.