Da fehlen einem echt die Worte…

Konfiguration von netatalk
Auf der Serverseite muß nach der Installation von netatalk lediglich eine nutzerbasierte Freigabe für die Time Machine erstellt werden. Hierzu könnte eine Zeile ähnlich der folgenden in die AppleVolumes.default eingetragen werden:

/mnt/timemachine/$u "Time Machine von $u" options:tm,upriv,usedots dbpath:/mnt/timemachine/$u

Wichtig ist an dieser Stelle die Option tm, wodurch die Freigabe als Time-Machine-Laufwerk gekennzeichnet wird. Der Platzhalter $u wird durch den Namen des angemeldeten Benutzers ersetzt.

Konfiguration der Time Machine
Auf der Clientseite kann nun die Time Machine konfiguriert werden. Sollte die Freigabe nicht in der Liste der verfügbaren Laufwerke auftauchen, so muß dieses Feature zunächst am Terminal über die Eingabe des folgenden Befehls freigeschaltet werden:

defaults write com.apple.systempreferences TMShowUnsupportedNetworkVolumes 1

Danach sollte die Freigabe auftauchen und auch ausgewählt werden können.

Hintergrund
Was passiert nun? Die Time Machine wird mit dem ersten Backup ein sogenanntes Sparse Bundle anlegen, da das Dateisystem auf der Freigabe kein HFS mit Journaling ist. Mit jedem Backup wird zunächst das Image gemountet. Nach dem Backup wirden dieses auch wieder freigegeben. Dies geschieht vollautomatisch, der Anwender muß sich um nichts kümmern.
Sieht man sich nun das Sparse Bundle mal etwas genauer an, so wird man feststellen, daß es aus Bands der Größe 8 MB besteht:

ls -l jupiter.sparsebundle/bands/

total 377536844
-rw-------  1 artanis  users  8388608 Jan 20 23:48 0
-rw-------  1 artanis  users  8388608 Jan 20 23:48 1
-rw-------  1 artanis  users  8388608 Jan 18 23:14 10
-rw-------  1 artanis  users  8388608 Aug 28 13:06 1000
[...]

Nun kann man sich leicht vorstellen, was das bedeutet, wenn man genügend Daten für die Time Machine hat: Es werden tausende von Dateien in nur einem Verzeichnis abgelegt:

ls -l jupiter.sparsebundle/bands/ | wc -l
    45911

Das mag dem Otto Normalverbraucher zwar egal sein, aber auf der Serverseite bedeutet es für das Betriebssystem einen Heidenaufwand. Nicht zuletzt kann die Performance der Time Machine selbst darunter leiden.

Wer jedoch genug Zeit übrig hat, kann eine Konvertierung des Sparse Bundles in Betracht ziehen. So wird laut Manpage von hdiutil eine Band-Size von bis zu 128 MB unterstützt. Vor der Konvertierung sollten zwingend die Time Machine des betreffenden Nutzers abgeschaltet und die Freigabe mit dem Sparse Bundle gemountet werden. Mit der Eingabe des folgenden Befehls im Terminal von MacOS X kann die Konvertierung durchgeführt werden:

hdiutil convert jupiter.sparsebundle -format UDSB -tgtimagekey sparse-band-size=262144 -verbose -o _jupiter.sparsebundle

Die Dateinamen müssen natürlich entsprechend angepaßt werden, Snow Leopard benennt das Sparse Bundle gemäß des Rechnernamens, Leopard vergibt den Namen nach dem Muster rechnername_macadresse.sparsebundle. Im obigen Beispiel ist es jupiter.sparsebundle. Die Option format gibt das neue Format an, wir bleiben bei einem Sparse Bundle. Die Option tgtimagekey gefolgt vom Schlüssel sparse-band-size gibt die neue Band-Size an, der Wert berechnet sich aus der Anzahl von 512-Byte-Sektoren, die beim Wachsen hinzugefügt werden sollen (512 x 512 = 262144 Sektoren = 128 MB). Die Option o zu guter Letzt gibt den Namen des neuen Images an.
Diese Operation dauert je nach Größe des Images und verwendetem Betriebssystem mehrere Stunden.
Nach Abschluß der Konvertierung müssen die Images ggf. umbenannt werden, damit die Time Machine nach dem Einschalten auch auf das richtige Image zugreift.

In meinem Fall hat die Konvertierung eines 360 GB großen Sparse Bundles mit Lion ca. 20 Stunden gedauert, das entspricht einem Durchsatz von ca. 5 MB/s. Snow Leopard hätte vermutlich etwas um die 72 Stunden benötigt, der Versuch schlug jedoch fehl, weil sich das verwendete Notebook zum unpassendsten Zeitpunkt in den Ruhezustand verabschiedete. Meine Empfehlung daher: Einen Desktoprechner verwenden, am besten per LAN-Kabel verbunden, dann sollte das problemlos klappen.
Die Anzahl der Bands hat sich im Beispiel von über 45000 auf “nur noch” 2700 verringert, nebenbei wurden ca. 25% Speicher freigemacht. Hier die Ausgabe von hdiutil:

hdiutil: convert: processing "jupiter.sparsebundle"
[...]
Driver Descriptor Map (DDM : 0) lesen …
Apple (Apple_partition_map : 1) lesen …
disk image (Apple_HFSX : 2) lesen …
...............................................................................
Dauer: 19h 11m 21.468s
Geschwindigkeit: 4.9M Byte/s
Ersparnis: 73.0 %
DIDiskImageConvertWithDiskImage: converter returned 0
created: /Volumes/Time Machine von artanis/_jupiter.sparsebundle
hdiutil: convert: result: 0

Weitere Informationen:
hdiutil(1) Mac OS X Manual Page
10.5: Improve networked Time Machine performance – Mac OS X Hints

“Ich hätte gern einen Kindersitz…”
“Haben wir…”
“Einen rückwärtsgerichteten…”
“… nicht.”

Über das Portal für Kindersicherheit bin ich dann auf den Kindersitz BeSafe iZi Combi X3 von HTS gestoßen und war überrascht, daß dieser in Deutschland über BabyOne bezogen werden kann. Einen Anruf später war diese Information verifiziert. Die Probe in einer Filiale vor Ort war erfolgreich und nun nach gut einer Woche ist der – aufgrund spezieller, besonderer Farbwünsche – bestellte Sitz eingetroffen.

Heute dann der Einbau…

An sich garnicht soo kompliziert und man fragt sich, warum der ADAC dort abgewertet hat. Wenn man mal davon absieht, daß man sein halbes Auto zerlegen muß…
Nein im Ernst, das einzig Aufwendige war es, eine Schiene des Beifahrersitzes zu lösen, um darunter einen Befestigungsgurt durchführen zu können. Der Rest ist das übliche Festgurten und gut. Natürlich kann man so einen Sitz nicht mal eben in ein anderes Auto einbauen, aber das ist auch kaum das Ziel, denke ich.

Der Kindersitz hat genug Platz im Wagen, sitzt absolut fest, sogar fester als die Babyschale zuvor und die erste Fahrt darin hat unserem Zwerg hervorragend gefallen. Positiv hervorzuheben ist auch die Möglichkeit, die Neigung des Sitzes in fünf Stufen einstellen zu können: Vom aufrechten Sitzen bis hin zur Schlafposition.

Weitere Informationen:
CarSeat.se
keep-kids-harnessed.org
reboard-kindersitze.at
BeSafe

Die Ausgangssituation

Als Beispiel sei folgendes übersichtliches Domänenmodell gegeben:

Ein Konto (Account) mit seinen Daten ist genau einem Kunden (Customer) über die Eigenschaft owner zugeordnet. Ein zugehöriges Set an DTOs könnte wie folgt aussehen:

Beziehungen werden aufgelöst und für die tabellarische Anzeige aller Konten wäre es schön, den Namen des Kunden zu sehen (AccountDTO#customerName). Außerdem wird für die Erfassung eines Kontos nur die ID des Kunden benötigt, um die Strukturen im Backend aufzubauen (AccountDTO#customerId).

Nun würde man sich vermutlich hinsetzen und Methoden schreiben, um die Daten aus den Domänenobjekten in die zugehörigen DTOs zu kopieren.

Lösungsansatz

Ziel der Lösung soll es sein, mit möglichst wenig manuellem Eingreifen eine automatische Übertragung der Daten vom Quell- in das Zielobjekt zu ermöglichen. Im Java-Umfeld gibt es mit den BeanUtils von Apache Commons eine Bibliothek, die den Umgang mit Java-Klassen in Bezug auf den Datentransfer vereinfacht. Diese kann man also verwenden, um praktisch mit einem Einzeiler die Daten von einem Objekt in das andere zu übertragen:

Account orig = ...
AccountDTO dest = new AccountDTO();
BeanUtils.copyProperties(dest, orig);

Allerdings kopiert diese Methode nur die primitiven Eigenschaften gleichen Namens und steigt schlimmstenfalls bei inkompatiblen Typen aus. Außerdem löst diese Methode nicht das Problem der beiden Eigenschaften Account#customerId und Account#customerName, die ja aus einem referenzierten Objekt bezogen werden. Es sind also einige Erweiterungen notwendig, die ich durch Annotationen verfügbar mache.

Neben den Annotationen gibt es zudem Factory-Klasse, in der die eigentliche Funktionalität implementiert ist: Die Auswertung der Annotationen und die Übertragung der Eigenschaften gemäß der Konfiguration.

Die Annotationen

Folgende Annotationen habe ich eingeführt:

• @DTOAttribute für die genauere Angabe des Quellwertes
• @DTOIgnore, um eine Eigenschaft zu ignorieren
• @DTOConverter für die Konvertierung eines Wertes zwischen Quelle und Ziel
• @DTO für die optionale Validierung von Datentypen

@DTOAttribute

Um die Quelle einer Eigenschaft genauer bestimmen zu können, kann die Annotation @DTOAttribute verwendet werden:

@Target({ElementType.FIELD})
@Retention(RetentionPolicy.RUNTIME)
@Documented
public @interface DTOAttribute {
    String source();
}

Der Schlüssel source gibt an, woher ein Wert bezogen werden soll. Hier kann man nun mit Punktnotation auch über Eigenschaften navigieren. Hier ist im Prinzip alles erlaubt, was die BeanUtils verarbeiten können. Wichtig für die spätere Verarbeitung ist die Retention, die auf RUNTIME eingestellt werden sollte, damit die Annotation für die JVM zur Laufzeit sichtbar ist.

@DTOIgnore

Durch die Marker-Annotation @DTOIgnore kann man eine Eigenschaft im DTO von der Befüllung aus einer gleichnamigen Eigenschaft im Quellobjekt ausschließen.

@Target({ElementType.FIELD})
@Retention(RetentionPolicy.RUNTIME)
@Documented
public @interface DTOIgnore { }

@DTOConverter

Die Annotation @DTOConverter löst das Problem der inkompatiblen Eigenschaften durch Angabe eines Konverters über den Schlüssel converter.

@Target({ElementType.FIELD})
@Retention(RetentionPolicy.RUNTIME)
@Documented
public @interface DTOConverter {
    @SuppressWarnings("rawtypes")
    Class<? extends DTOAttributeConverter> converter();
}

Der Konverter muß die Schnittstelle DTOAttributeConverter implementieren. Diese Schnittstelle stellt eine Methode convert() zur Verfügung, mit der die Eigenschaft aus dem Quellobjekt in die Eigenschaft im Zielobjekt konvertiert wird. Die Schnittstelle ist generisch, angegeben werden jeweils der Eigenschaften-Typ in der Quelle (S) und im Ziel (D).

public interface DTOAttributeConverter<S, D> {
    D convert(S src);
}

@DTO

Diese Annotation dient in erster Linie der Validierung der verwendeten Objekte. Sie ermöglicht eine Prüfung, ob das angegebene DTO für ein Quellobjekt als gültiges Ziel akzeptiert wird. So kann man zur Entwicklungszeit sicherstellen, daß die korrekten Paarungen aus Domänenobjekt und DTO an die Factory-Methode übergeben werden.

@Target({ElementType.TYPE})
@Retention(RetentionPolicy.RUNTIME)
@Documented
public @interface DTO {
    Class<?> target();
}

Die Factory-Klasse

Als Basis für die Übertragung der Eigenschaften dient die oben gezeigte Methode. Ein Blick in die Quellen der BeanUtils zeigt, daß nach Ermittlung aller Eigenschaften diese nach und nach in das Ziel kopiert werden. Ich mache mir dieses Vorgehen an dieser Stelle nicht nur zu eigen, sondern erweitere es zudem um die Verarbeitung der eingeführten Annotationen. Diese Operation lagere ich in eine Klasse namens DTOFactory aus, die eine überladene, öffentliche Methode zur Verfügung stellt: createDTO. In der ersten Version erwartet die Methode zwei Instanzen, eine vom Typ des DTOs und eine vom Typ der Quelle. Die Überladung ermöglicht es, nur den Typen des DTOs sowie eine Instanz der Quelle anzugeben. Intern erzeugt diese Methode zunächst die notwendige Instanz des DTOs anhand des übergebene Typen und leitet die Verarbeitung an die erste Methode weiter.

public class DTOFactory {
 
    /** Cache für Konverter. */
    private HashMap<Field, DTOAttributeConverter<Object, Object>> converters =
            new HashMap<Field, DTOAttributeConverter<Object, Object>>();
 
    public <T> T createDTO(Class<T> dtoClass, Object source) {
        try {
            T dto = dtoClass.newInstance();
            createDTO(dto, source);
            return dto;
        } catch (IllegalArgumentException iae) {
            throw iae;
        } catch (Exception e) {
            return null;
        }
    }
 
    public <T> void createDTO(T dto, Object source) {
        // Schritt 1: Parameterprüfung
        if (dto == null) {
            throw new IllegalArgumentException("Target object may not be null.");
        }
        if (source == null) {
            throw new IllegalArgumentException("Source object may not be null.");
        }
 
        // Schritt 2: Annotation @DTO
        DTO aDto = dto.getClass().getAnnotation(DTO.class);
        if (aDto != null && !aDto.target().equals(source.getClass())) {
            throw new IllegalArgumentException("Source type '" +
                    aDto.target().getName() + "' expected, but found '" +
                    source.getClass().getName() + "'.");
        }
 
        // Schritt 3: Eigenschaften ermitteln und verarbeiten
        PropertyDescriptor[] props = PropertyUtils.getPropertyDescriptors(dto);
        for (int i = 0; i < props.length; i++) {
            String name = props[i].getName();
 
            // Schritt 3.1
            if ("class".equals(name) || !PropertyUtils.isWriteable(dto, name)) {
                continue; // class-Eigenschaft von Object ignorieren bzw. Ziel nicht änderbar
            }
 
            try {
                Field field = dto.getClass().getDeclaredField(name);
 
                // Schritt 3.2: auf DTOIgnore prüfen und Eigenschaft ggf. überspringen
                if (field.getAnnotation(DTOIgnore.class) != null) {
                    continue;
                }
 
                Object value = null;
 
                // Schritt 3.3: auf DTOAttribute-Annotation prüfen
                DTOAttribute att = field.getAnnotation(DTOAttribute.class);
                if (att != null) {
                    if (PropertyUtils.isReadable(source, att.source())) {
                        // Wert aus angegebener Quelle holen
                        value = PropertyUtils.getProperty(source, att.source());
                    }
                } else if (PropertyUtils.isReadable(source, name)) { // Standardverhalten
                    // Quelle anhand gleichen Namens auslesen
                    value = PropertyUtils.getProperty(source, name);
                }
 
                // Schritt 3.4: wenn DTOConverter angegeben, Konvertierung durchführen
                DTOConverter conv = field.getAnnotation(DTOConverter.class);
                if (conv != null) {
                    DTOAttributeConverter<Object, Object> converter =
                            getConverter(conv.type(), conv.name(), field);
                    value = converter.convertFromSource(value);
                }
 
                // Schritt 3.5: Wert in Ziel schreiben
                BeanUtils.copyProperty(dto, name, value);
            } catch (Exception e) {
                // ignorieren
            }
        }
    }
 
    @SuppressWarnings({ "unchecked", "rawtypes" })
    protected DTOAttributeConverter<Object, Object> getConverter(
            Class<? extends DTOAttributeConverter> type,
            String name, Field field) throws Exception {
        DTOAttributeConverter<Object, Object> converter = converters.get(field);
        if (converter == null) {
            converter = type.newInstance();
            converters.put(field, converter);
        }
        return converter;
    }
}

Schauen wir uns das Vorgehen der Methode näher an. Im Schritt 1 wird zunächst geprüft, ob Quelle oder Ziel null sind. Dies ist untersagt, daher wird eine IllegalArgumentException geworfen.
Im zweiten Schritt wird das Vorhandensein der Annotation @DTO überprüft. Ist das der Fall, so wird der darin angegebene, erwartete Typ des Quellobjekts mit dem tatsächlichen Datentypen verglichen. Stimmen beide Typen nicht überein, so wird auch an dieser Stelle eine Ausnahme ausgelöst.
Anschließend werden die verfügbaren Eigenschaften mit Hilfe der BeanUtils ermittelt und verarbeitet. Hierzu wird zunächst geprüft, ob es sich um die Eigenschaft class handelt oder die Eigenschaft im DTO nicht veränderbar ist (Schritt 3.1). In diesem Fall wird sie einfach übersprungen. Auch im Falle der Annotation mit @DTOIgnore wird die betroffene Eigenschaft übersprungen (Schritt 3.2). In Schritt 3.3 wird nun der Wert aus der Quelle gelesen. Falls die Annotation @DTOAttribute existiert, wird der Wert aus der darin angegebenen Quelle gelesen, andernfalls aus der gleichnamigen Eigenschaft (Standardverhalten). Schritt 3.4 prüft auf die Annotation @DTOConverter und versucht in diesem Falle eine Konvertierung des Wertes mit Hilfe des angegebenen Konverters. Die Konverter werden nach der Erzeugung zwischengespeichert, um sie ggf. wiederverwenden zu können. Im letzten Schritt (3.5) wird dann der Wert in das Ziel geschrieben.
Falls irgendwann während der Verarbeitung einer Eigenschaft ein Fehler auftritt, so wird die daraus resultierende Ausnahme verschluckt und die Eigenschaft damit übersprungen.

Anwendungsbeispiel

Wir wenden nun die Annotationen auf das oben angegebene Domänenmodell an, um dann die Daten aus einer Instanz der Klasse Account in eine Instanz des zugehörigen DTOs zu übertragen:

public class AccountDTO {
    private Long id;
    private String bic;
    private String iban;
    @DTOAttribute(source="owner.id")
    private Long customerId;
    @DTOAttribute(source="owner.name")
    private String customerName;
 
    // Getter und Setter (notwendig)
}

// Objektnetz erzeugen
Customer c = new Customer();
c.setId(new Long(42));
c.setName("Max Mustermann");
c.setEmailAddress("max@mustermann.com");
Account a = new Account();
a.setId(new Long(21));
a.setBic("WELADED1KSD");
a.setIban("DE34567890123456");
a.setOwner(c);
 
// das DTO erzeugen und mit Daten befüllen
DTOFactory factory = new DTOFactory();
AccountDTO dto = factory.createDTO(AccountDTO.class, a);

Et voilà, ein Einzeiler ermöglicht uns nun bei korrekt annotiertem DTO-Typen eine Übertragung aller gewünschten Eigenschaften aus dem Domänenobjekt in das Ziel-DTO.

Mögliche Erweiterungen

Eine denkbare Erweiterung für die Konvertierung wäre die Verwendung von vordefinierten Beans bspw. in einem Spring-Umfeld. So könnte eine Eigenschaft name der Annotation @DTOConverter hinzugefügt werden, mit welcher die Bean-ID des zu verwendenden Konverters angegeben werden könnte. Gleichzeitig würde eine Ableitung der DTOFactory nötig, in welcher dann bei Vorhandensein eines Namens eine Auflösung aus der Spring-BeanFactory in der Methode getConverter() versucht werden würde.

Die Schnittstelle DTOAttributeConverter kann um eine Methode erweitert werden, die den Konverter in die Lage versetzt, auch die Richtung DTO -> Domänenobjekt mit einer Konvertierung der Daten zu bedienen. Auch in diesem Fall ist dann eine Erweiterung der Factory-Klasse notwendig.

Jedenfalls fragte mich vor einigen Tagen ein Kollege, ob ich denn der “Merge-Hölle” entkommen sei, kurz nachdem ich einige Commits durchgeführt hatte. Wie er darauf kommt? Er hat sich die grafische Darstellung der Historie angesehen, die ihn irgendwie an einen Verschiebebahnhof erinnerte:

Einen sehr verrückten, möchte ich hinzufügen…

(via KeenTech)

Was mir gefällt
Der Stromverbrauch dürfte sich aufgrund des verbauten 150-Watt-Netzteils in Grenzen halten. Kein Vergleich zu dem Zeug, was man heute sonst kaufen kann, da gibt’s ja kaum noch was unter 400 Watt (Atomkraftwerk, anyone?).

Der Server ist cold-plug-fähig, d.h. bis zu vier Festplatten werden jeweils in einen Rahmen eingeschraubt, der dann einfach eingeschoben wird. Damit entfällt auch das Kabelgewirr.
Der Rechner ist unglaublich leise, da bis auf den Gehäuselüfter keine Lüfter im Gehäuse verbaut sind. Vielmehr ist der Prozessor (Athlon Neo N36L) passiv gekühlt.

Die meisten Arbeiten gehen ohne Zuhilfenahme von Werkzeugen vonstatten: Festplatteneinbau (wie erwähnt), Speicherwechsel, … Und sollte dennoch einmal irgendwo eine Schraube gelöst werden müssen, dann ist das dafür notwendige Werkzeug an der Türinnenseite befestigt.

Was mir nicht gefällt
Da das Gehäuse des Servers wirklich kompakt ist, gibt es starke Einschränkungen bei der Erweiterbarkeit. So muß man darauf achten, daß nur PCI-Expresskarten mit Low Profile (halbe Länge, halbe Höhe) hineinpassen. Das hat bei mir bspw. dazu geführt, daß der Sound extern in Form einer USB-Soundkarte erzeugt wird.

Und der alte?
Der alte Server ist mit seiner Ablösung der letzte Rechner, den ich selbst zusammengeschraubt habe. Als Gehäuse kam ein Arctic Cooling mit verändertem Design zum Einsatz, das aufgrund seiner gummigelagerten Lüfter praktisch nicht hörbar war. Diese Gummilagerungen sind allerdings auch ein Problem: Nach fünf Jahren sind die ersten porös geworden und die betroffenen Lüfter aus ihren Halterungen gefallen. So geschehen mit einem der Lüfter vor einem Jahr und mit einem weiteren vor einigen Wochen, als ich den Rechner nur mal angehoben habe.
Die Seagate-Festplatten haben an sich über die Jahre ihren Dienst versehen, jedoch sind bei einer zum Schluß hin und wieder I/O-Probleme aufgetaucht, die zu Serverabstürzen geführt haben.

Fazit
Wesentlicher Austauschgrund war zweifelsfrei die Hardware. Ich gebe auch dem neuen Server wohl nicht mehr als fünf Jahre. Aber ich denke, das ist ein akzeptabler Zeitraum, in dem ich hoffe, daß mir der kleine neue gute und vor allem stabile Dienste leisten wird.