Sun 10 January 2016

Typsicheres verlinken mit Java 8

Im heutigen Blog-Post geht es um Webrahmenwerke. Genauer: es geht darum, wie man auf typsichere Art und Weise Links zu Controllern erzeugt. Typsicher in dem Sinne, dass man Variablen im Routing nur durch Werte des selben Typs ersetzen kann, den der Controller auch tatsächlich erwartet. Übergibt man die falsche Anzahl an Werten oder Werte des falschen Typs, soll der Code erst gar nicht kompilieren – in anderen Worten: Es sollen nicht erst Exceptions zur Laufzeit geworfen werden, sondern bereits beim kompilieren. Für das Beispiel beschränken wir uns auf Pfad-Variablen.

Die Code-Beispiele für die Controller sind dabei lose an JAX-RS orientiert. Es werden die folgenden Konventionen benutzt:

  • Methoden, die Requests behandeln, haben lediglich die Pfad-Variablen als Parameter. Die Reihenfolge der Parameter ist dabei die Reihenfolge, in der sie im Routing-Template definiert sind.

Note

In diesem Blog-Beitrag wird nur die Methode vorgestellt, mit der man Links erstellen kann. Ein Router, der Requests auf Controller dispatcht, wird nicht vorgestellt.

Außerdem wird eine gewisse Vertrautheit mit Java 8 (insbesondere Lambdas) vorausgesetzt sowie auch ein wenig mit JAX-RS. Für eine Intro zu Lambdas siehe etwa den Lambda Quick Start

Prior Art

Da Links erzeugen ein Recht häufiges Problem ist, gibt es natürlich so einiges an Prior Art. Wahrscheinlich in so ziemlich jedem Webrahmenwerk, in den unterschiedlichsten Ausprägungen. Ich habe stellvertretend einmal drei herausgegriffen:

  • Pyramids route_url

    Zeigt schon mal die grobe Idee, wenn auch in Python und nicht in Java. Gewisse Fehler werden abgefangen (falsche Anzahl an Argumenten zum Beispiel). Allerdings passiert alles zur Laufzeit. Man braucht also eine recht gut ausgeprägte Test-Suite, um Fehler beim Linken zu erkennen.

  • Declarative Hyperlinking in Jersey

    Mit Annotationen umgesetzt und dadurch stringly typed. Fehler werden erst zur Laufzeit erkannt.

  • Spring HATEOAS

    Kommt schon recht nahe dran. Insbesondere Building links pointing to methods geht stark in die Richtung:

    Method method = PersonController.class.getMethod("show", Long.class);
    Link link = linkTo(method, 2L);
    

    Allerdings funktioniert die Methoden-Auflösung zur Laufzeit und via Name als String. Die Parametertypen müssen explizit angegeben werden und die Typüberprüfung passiert ebenfalls erst zur Laufzeit.

Warum nicht Methodenreferenzen?

Da Java 8 endlich Methodenreferenzen eingeführt hat, liegt natürlich die Idee nahe, es damit irgendwie zu versuchen.

Stellen wir uns vor, dass wir den folgenden Controller hätten:

@Path("/hello")
class HelloWorldController {

    @GET
    public String hello() {
        return "Hello, world!";
    }
}

Als erstes erstellen wir ein FunctionalInterface. Das Interface soll eine Referenz auf eine Methode der Klasse H darstellen, die keine Parameter entgegen nimmt und ein R als Ergebnis zurück gibt. Dementsprechend sieht das Interface wie folgt aus:

@FunctionalInterface
interface NoParam<H, R> {
    R apply(H h);
}

Dieses Interface kann aus einer Methodenreferenz erstellt werden:

NoParam<HelloWorldController, String> hello = HelloWorldController::hello;
// Aufrufen könnte man die Methode jetzt so (angenommen,
// someHelloWorldController ist eine Instanz von HelloWorldController):
String result = hello.apply(someHelloWorldController);
assert "Hello, world!".equals(result);

Folglich können wir damit dann die folgende Methode bauen:

<H, R> URI linkTo(NoParam<H, R> handler) {
    // Hier der Code, der die Routing-Informationen von handler ausliest und
    // daraus dann eine URI baut
}

Jetzt ist es möglich, aus einem anderen Controller heraus einen Link zu unserer gewünschten Methode HelloWorldController#hello() zu bauen:

URI helloLink = linkTo(HelloWorldController::hello);

Wenn wir ein Argument zu viel übergeben würden (zum Beispiel, weil wir denken, dass die hello-Ressource einen Namen entgegen nimmt, um einen personalisierten Gruß zu erzeugen, kompiliert der Code nicht:

java: no suitable method found for linkTo(HelloWorldController::hello)

Ziel erreicht. Um tatsächlich Pfad-Parameter zu unterstützen, müssen wir jetzt einfach (relativ mechanisch) weitere Interfaces einführen.

Erweitern wir zunächst unseren Controller um einen personalisierten Gruß:

@GET
@Path("/{name}")
public String greeting(String name) {
    return "Hello, " + name + "!";
}

Der Parameter name repräsentiert hierbei die Pfad-Variable name. Links dazu können dann folgenderweise erstellt werden:

URI link = linkTo(HelloWorldController::greeting, "Joe");

Dazu führen wir ein weiteres Interface ein:

@FunctionalInterface
interface OneParam<H, P, R> {
    R apply(H h, P p);
}

Wenig überraschend steht H hierbei für den Typ des Controllers, P für den Parameter und R für den Rückgabewert.

Desweiteren muss eine weitere Überladung von linkTo eingeführt werden:

URI linkTo(OneParam<H, P, R> handler, P param) {
    // Hier wieder Routing-Infos von handler auslesen und dann param einsetzen
}

Das ist zum Implementieren zwar ein wenig wortreich (für jede Anzahl an Pfad-Variablen ein eigenes Interface und eine entsprechende linkTo-Methode), aber das muss man zum Glück nur einmal tun und außerdem hat man ja auch nicht unendlich lange Pfade in der Praxis.

Viel gravierender ist jedoch: es funktioniert überhaupt nicht. Man kann zwar aus einer Methodenreferenz ein Lambda bauen. Allerdings geht die Information, aus welcher Methode das Lambda erzeugt wird, dabei verloren. Wir brauchen die Information, um welche Methode es sich handelt, jedoch, da wir ansonsten nicht an die Route kommen.

Proxies to the rescue

Da die Antwort auf die meisten Probleme in Java "(dynamische) Code-Generierung" ist, probieren wir es doch auch einmal damit. Genauer gesagt dynamische Proxy-Objekte. Die Idee ist dabei folgendermaßen:

  • Wir erzeugen uns ein Proxy-Objekt vom gleichen Typ der Handler-Klasse.
  • Wir rufen die Methode auf, die übergeben wurde (genauer gesagt, das Lambda)
  • Das Proxy-Objekt ruft nicht wirklich die eigentliche Methode auf, sondern merkt sich einfach, welche Methode aufgerufen wurde.
  • Wir holen uns die gemerkte Methode vom Proxy-Objekt.

Gehen wir davon aus, dass wir eine Klasse MethodResolver<T>, die die Proxy-Objekte erstellt, könnte unsere linkTo-Methode also in der Art aussehen:

URI linkto(Class<H> handlerClass, OneParam<H, P, R> handler, P param) {
    MethodResolver<H> methodResolver = MethodResolver.on(handlerClass);
    handler.apply(methodResolver, param);
    Method method = methodResolver.resolve();
    // Mit handlerClass und method kann man jetzt an die Routing-Informationen
    // kommen
}

Die meisten AOP-Rahmenwerke bieten Method-Interceptors an, mit denen man das recht einfach umsetzen kann. Für Proxetta könnte ein entsprechendes Advice zum Beispiel so aussehen:

/**
 * MethodResolver advice applied on all methods. It puts the method in a class
 * variable that can be accessed later using reflection.
 */
class MethodResolverAdvice implements ProxyAdvice {

    public Method method;

    public Object execute() {
        final Class<?> targetClass = targetClass();
        final String methodName = targetMethodName();
        final Class<?>[] argumentTypes = createArgumentsClassArray();
        try {
            method = targetClass.getMethod(methodName, argumentTypes);
        } catch (NoSuchMethodException e) {
            throw new RuntimeException(e);
        }
        return returnValue(null);
    }
}

Beispielimplementierung

Im Github-Repo java8_linking_experiments habe ich eine Beispielimplementierung für das Ratpack-Mikro-Webrahmenwerk umgesetzt.

Thu 03 December 2015

Let's Encrypt!

Seit heute steht Let's Encrypt als öffentliche Beta zur Verfügung. Mit Let's Encrypt kann sich jeder einfach und kostenlos ein X.509-Zertifikat erstellen lassen. Somit gibt es keine Ausrede mehr, nicht HTTPS zu benutzen. Deswegen versucht dieses Blog auch mit gutem Beispiel voran zu gehen:

Mon 10 August 2015

AmazonS3Client mit Pithos benutzen

Pithos, ein S3-Klon, der Cassandra zur Ablage benutzt, unterstützt aktuell nur Signaturen in V2. S3 unterstützt inzwischen aber eigentlich nur noch V4, weswegen der offizielle AmazonS3Client ein paar Probleme bei der Verwendung mit Pithos macht:

 Exception in thread "main" com.amazonaws.services.s3.model.AmazonS3Exception: The request signature we calculated does not match the signature you provided. Check your key and signing method. (Service: Amazon S3; Status Code: 403; Error Code: SignatureDoesNotMatch; Request ID: 1e04fbc1-bf91-4bb3-af1e-6829ce549524), S3 Extended Request ID: 1e04fbc1-bf91-4bb3-af1e-6829ce549524
      at com.amazonaws.http.AmazonHttpClient.handleErrorResponse(AmazonHttpClient.java:1182)
      at com.amazonaws.http.AmazonHttpClient.executeOneRequest(AmazonHttpClient.java:770)
      at com.amazonaws.http.AmazonHttpClient.executeHelper(AmazonHttpClient.java:489)
      at com.amazonaws.http.AmazonHttpClient.execute(AmazonHttpClient.java:310)
      at com.amazonaws.services.s3.AmazonS3Client.invoke(AmazonS3Client.java:3608)
      at com.amazonaws.services.s3.AmazonS3Client.getObject(AmazonS3Client.java:1135)
      at com.amazonaws.services.s3.AmazonS3Client.getObject(AmazonS3Client.java:1015)
...

Mit einem kleinen (Trick|Hack) kann man den Client dann aber trotzdem dazu bewegen, V2 zum Signieren zu benutzen:

private static final String PITHOS_ENDPOINT = "s3.example.com";
private static final String ACCESS_KEY = "AKIAIOSFODNN7EXAMPLE";
private static final String SECRET_KEY = "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY";

// …

final AWSCredentials credentials = new BasicAWSCredentials(ACCESS_KEY, SECRET_KEY);
final ClientConfiguration clientConfig = new ClientConfiguration();
clientConfig.setSignerOverride("S3SignerType");
clientConfig.setProtocol(Protocol.HTTP);
final AmazonS3Client s3Client = new AmazonS3Client(credentials, clientConfig);
s3Client.setEndpoint(PITHOS_ENDPOINT);

Getested mit dem AWS Java SDK Version 1.10.10. Mit etwas Suchen kann man das auch in den Issues finden: #277 und #372.

Sun 24 August 2014

Generic Heterogenous Containers Using Super Type Tokens

Wie man am Titel bereits leicht erraten kann: heute geht es (zum ersten Mal in diesem Blog?) um Java. Genauer: Wie man heterogene Container in Java umsetzen kann.

Zunächst zur Idee: Wir wollen eine Klasse Favorites implementieren, in die man seine Lieblingsobjekte speichern und auch wieder abrufen kann. Damit man nicht einfach irgendein beliebiges Objekt zurückbekommt, sondern ein Objekt von einem bestimmten Typ, übergibt man beim Speichern und abrufen die Klasse des Objekts.

Die API dafür sieht so aus:

public class Favorites {
    public <T> void putFavorite(Class<T> type, T instance);
    public <T> getFavorite(Class<T> type);
}

Note

Der geneigte Java-erfahrene Leser wird direkt erkennen, dass das Beispiel aus Effective Java von Joshua Bloch ist. Das ist absolut richtig und auch Teile des hier gezeigten Codes stammen aus diesem Buch, das durchaus lesenswert ist (auch für Nicht-Java-Programmierer).

Die erste Idee, das zu implementieren, könnte etwa so aussehen:

public class Favorites {
    private final Map<Class<?>, Object> favorites = new HashMap<>();

    public <T> void putFavorite(Class<T> type, T instance) {
        favorites.put(checkNotNull(type), instance);
    }

    public <T> T getFavorite(Class<T> type) {
        return type.cast(favorites.get(type));
    }
}

Man nimmt also einfach das Klassenobjekt des Werts als Schlüssel in einer Map, um den Wert zu speichern. Beim Auslesen wird dann auch wieder das Klassenobjekt übergeben, womit man an den Wert kommt. Wurde für den Typ kein Wert hinterlegt, wird einfach nichts gefunden.

An sich scheint das auch ganz gut zu funktionieren:

Favorites f = new Favorites();
f.putFavorite(String.class, "Some string");
f.putFavorite(Integer.class, 1234);
System.out.printf("%s %d%n", f.getFavorite(String.class), f.getFavorite(Integer.class));

Auch der Fall, dass kein Wert hinterlegt wurde für den Typ, funktioniert einfach: favorites.get(type) gibt dann null zurück und null kann zu allem gecastet werden.

Und hätte Java jetzt nicht Type Erasure, wäre der Blogpost auch schon zu Ende. Da Java allerdings Type Erasure hat, stößt man recht bald auf ein Problem, wenn man auf versucht, ein Generic in den Container zu packen: List<Integer>.class ist ein Syntaxfehler. Das liegt daran, dass List<Integer> und List<String> dasselbe Klassenobjekt haben, nämlich List.class. Das bedeutet aber auch, dass man eine Liste von Strings in Favorites packen kann und danach als Liste von Integern auslesen kann (bzw. man kann es zumindest versuchen):

f.putFavorite(List.class, Arrays.asList("foo", "bar"));
List<Integer> values = f.getFavorite(List.class);

Wenn man das jetzt ausführt, scheint es sogar zu funktionieren. Jedenfalls läuft es anstandslos durch. Allerdings nur bis man dann den Wert tatsächlich einmal versucht als den angegebenen Wert zu verwenden:

Integer first = values.get(0);

Bei einer erneuten Ausführung wird jetzt eine Ausnahme geworfen:

Exception in thread "main" java.lang.ClassCastException: java.lang.String cannot be cast to java.lang.Integer

Bei genauem Hinschauen erkennt man auch bereits beim Kompilieren, dass hier potenziell zur Laufzeit etwas kaputt gehen könnte:

Favorites.java: warning: [unchecked] unchecked conversion
      List<Integer> values = f.getFavorite(List.class);
                                          ^
required: List<Integer>
found:    List

Ein gutes Beispiel dafür, dass man Compiler-Warnungen nicht einfach ignorieren sollte.

Das ist natürlich wenig zufriedenstellend. Ein Ausweg daraus sind die sogenannten Super Type Tokens, die man wie folgt verwenden kann:

TypeReference<List<String>> x = new TypeReference<List<String>>() {};

TypeReference kann jetzt zur Laufzeit nachsehen, welcher Wert als Typvariable übergeben wurde. Das wiederum kann dann Favorite für sich benutzen.

Die Implementierung von TypeReference:

import java.lang.reflect.ParameterizedType;
import java.lang.reflect.Type;

public abstract class TypeReference<T> {
    private final Type type;

    protected TypeReference() {
        Type superClass = getClass().getGenericSuperclass();
        if (superClass instanceof Class<?>) {
            throw new RuntimeException("Missing type parameter");
        }

        type = ((ParameterizedType) superClass).getActualTypeArguments()[0];
    }

    public Type getType() {
        return type;
    }
}

Und das angepasste Favorites:

import java.lang.reflect.Type;
import java.util.Arrays;
import java.util.HashMap;
import java.util.List;
import java.util.Map;

public class Favorites {
    private final Map<Type, Object> favorites = new HashMap<>();

    public <T> void putFavorite(TypeReference<T> typeReference, T instance) {
        favorites.put(typeReference.getType(), instance);
    }

    @SuppressWarnings("unchecked")
    public <T> T getFavorite(TypeReference<T> typeReference) {
        return (T) favorites.get(typeReference.getType());
    }

    public static void main(String[] args) {
        Favorites f = new Favorites();
        f.putFavorite(new TypeReference<String>() {}, "Some string");
        f.putFavorite(new TypeReference<Integer>() {}, 1234);
        f.putFavorite(new TypeReference<List<String>>() {}, Arrays.asList("foo", "bar"));
        System.out.printf("%s %d %s%n",
                          f.getFavorite(new TypeReference<String>() {}),
                          f.getFavorite(new TypeReference<Integer>() {}),
                          f.getFavorite(new TypeReference<List<Integer>>() {}));
    }
}

Die Ausgabe ist wie erwartet Some string 1234 null. Fertig ist er also, unser typsicherer heterogener Container, der auch mit Generics funktioniert (wenn auch etwas umständlich).

Oder fast. Wenn da dieses @SuppressWarnings("unchecked") nicht wäre. Immerhin haben wir vor einem Augenblick erst gesehen, dass man Compiler-Warnungen nicht ignorieren sollte. Und tatsächlich kann man auch für die neue Favorites einen Fall konstruieren, bei dem zur Laufzeit eine Ausnahme fliegt:

static <T> List<T> favoriteList(Favorites f) {
    TypeReference<List<T>> typeReference = new TypeReference<List<T>>(){};
    List<T> result = f.getFavorite(typeReference);
    if (result == null) {
        result = new ArrayList<T>();
        f.putFavorite(typeReference, result);
    }
    return result;
}

public static void main(String[] args) {
    Favorites f = new Favorites();
    List<String> listOfStrings = favoriteList(f);
    List<Integer> listOfIntegers = favoriteList(f);
    listOfIntegers.add(42);
    String booooom = listOfStrings.get(0);
}

// java.lang.ClassCastException: java.lang.Integer cannot be cast to java.lang.String

Um diese Ausnahme zu vermeiden, müsste man die Typ-Argumente durchgehen und schauen, ob noch irgendwo eine TypeVariable vorkommt. Ein Beispiel, in dem das gemacht wird, ist GenericType<T> aus JAX-RS (Quelltext). Das würde aber noch immer zur Laufzeit eine Exception werfen und nicht zur Compile-Zeit einen Fehler produzieren.

Wed 20 August 2014

Neues bpaste.net: Pinnwand

ikanobori hat sich die Mühe gemacht und die Software, die auf bpaste.net läuft, komplett erneuert. Dabei hat er auch lange gewünschte neue Features umgesetzt. Außerdem ist bpaste.net damit gleichzeitig auf neue, leistungsfähigere Hardware umgezogen.

Neu ist:

  • Man kann Pastes löschen (via einem Löschen-Link)
  • Pastes können sich automatisch nach einer bestimmten Zeit löschen

Gleich geblieben ist:

  • API-Kompatibilität zu LodgeIt (hoffentlich zumindest)

Die Daten werden innerhalb der nächsten zwei Monate automatisch in das neue System übertragen. Aber nur, wenn man ein altes Paste öffnet. Danach werden die Daten unwiderruflich gelöscht sein.

Der Code befindet sich auf Github. Wünsche, Bugs und Anregungen bitte melden.

Wed 20 August 2014

Emacs: Open file in browser

Inspiriert vom Idea-GitLab-Integration-Plugin, das ein open file in browser anbietet, habe ich das ganze mal für Emacs gebaut:

(require 'magit)

(setq git-browser-url-templates
      '(("bitbucket.org" . "https://bitbucket.org/{{repo}}/src/{{branch}}/{{file-name}}#cl-{{lineno}}")
     ("github.com" . "https://github.com/{{repo}}/blob/{{branch}}/{{file-name}}#L{{lineno}}")
     ("pwmt.org" . "https://git.pwmt.org/?p={{repo}}.git;a=blob;f={{file-name}};hb={{branch}}#l{{lineno}}")))

(defun format-gitviewer-url (template vars)
  (let ((expand (lambda (match)
               (let* ((name (substring match 2 -2))
                      (value (assoc name vars)))
                 (unless value
                   (error (format "Unknown variable %s" name)))
                 (cdr value)))))
    (replace-regexp-in-string "{{.+?}}" expand template)))


(defun git-open-in-browser ()
  (interactive)
  (let* ((remote (magit-get-remote nil))
      (remote-url (magit-get "remote" remote "url"))
      (branch (substring (magit-get-tracked-branch) (+ 1 (length remote))))
      (file-name (magit-file-relative-name (buffer-file-name)))
      (lineno (line-number-at-pos)))
    (unless (string-match "\\(@\\|://\\|^\\)\\([^:@/]+?\\)[:/]\\([^/].*?\\)\\(.git\\)?$" remote-url)
      (error "Could not find repo name"))
    (let* ((host-name (match-string 2 remote-url))
        (repo-name (match-string 3 remote-url))
        (url-template (assoc host-name git-browser-url-templates)))
      (unless url-template
     (error (format "Could not find URL template for host %s" host-name)))
      (browse-url (format-gitviewer-url (cdr url-template)
                                     (list
                                      (cons "repo" repo-name)
                                      (cons "branch" branch)
                                      (cons "file-name" file-name)
                                      (cons "lineno" (number-to-string lineno))))))))

Wed 20 August 2014

Dekoratoren in Python, erklärt in Farbe

Präambel

Dieser Artikel ist schon ein paar Jahre alt und war eigentlich nur für den Gebrauch bei meinem damaligen Arbeitgeber gedacht. Damit sich aber endlich mal etwas in diesem Blog tut, habe ich mich entschlossen, ihn dennoch zu veröffentlichen.

Note

Die Code-Beispiele sind in Python 2-Syntax gehalten. Das Übersetzen nach Python 3 wird dem Leser als Übung überlassen.

Was sind Dekoratoren?

Wie der Namen bereits vermuten lässt, dekorieren Dekoratoren etwas. Bei Python sind es Funktionen bzw. Methoden und seit Version 2.6/3.0 auch Klassen. Ein Beispiel für Dekoratoren:

@decorator
def spam():
    print "Ich bin spam."

Note

Ein Hinweis für Java-Entwickler: Die Syntax sieht zwar ähnlich aus wie Annotations in Java, hat aber ansonsten nichts mit Annotations in Java zu tun.

Was passiert jetzt, wenn man den obigen Code ausführt?

>>> @decorator
... def spam():
...     print "Ich bin spam."
...
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
NameError: name 'decorator' is not defined

Der NameError ist jetzt natürlich wenig überraschend, schließlich wurde der Dekorator decorator noch nicht definiert. Im Folgenden werden wir das nachholen:

def decorator(func):
    print "Ich bin ein Dekorator und dekoriere", func.__name__
    return func

Was passiert jetzt, wenn man den obigen Code ausführt?

>>> def decorator(func):
...     print "Ich bin ein Dekorator und dekoriere", func.__name__
...     return func
...
>>> @decorator
... def spam():
...     print "Ich bin spam."
...
Ich bin ein Dekorator und dekoriere spam
>>> spam
<function spam at 0x7f8d95b3c488>

Und was, wenn man die dekorierte Funktion ausführt?

>>> spam()
Ich bin spam.

Wie einfach zu erkennen ist, hat unser simpler Beispiel-Dekorator keine direkte Auswirkung auf die dekorierte Funktion.

Ich weiß jetzt noch immer nicht, was ein Dekorator ist

Ein Beispiel alleine erklärt natürlich nicht, was ein Dekorator ist. Was ist also ein Dekorator? Ein Dekorator ist nichts anderes als ein Callable, das implizit als Argument die zu dekorierende Funktion bzw. Methode bzw. Klasse übergeben bekommt. Der Rückgabewert des Dekorators wird dann an den Namen der Funktion bzw. Methode bzw. Klasse gebunden. Anders ausgedrückt:

@decorator
def spam():
    pass

ist nichts anderes als syntaktischer Zucker für

def spam():
    pass
spam = decorator(spam)

Das ist auch der Grund, warum unser Beispieldekorator decorator die Funktion explizit wieder zurück gibt.

Das, was nach dem @ folgt, muss jedoch nicht zwingend ein Name sein. Vielmehr kann es ein beliebiger Ausdruck sein. Der Ausdruck wird evaluiert und das Ergebnis des Ausdrucks ist dann der Dekorator. Um das zu verdeutlichen, folgt jetzt ein Beispiel für eine Dekoratoren-Factory:

def decorator_for(name):
    """Ich bin eine Factory und ich gebe einen Dekorator zurück."""
    print "Erzeuge einen Dekorator für", name
    # Den eigentlichen Dekorator (aus dem vorigen Beispiel) zurück geben
    return decorator

@decorator_for("Csaba")
def spam():
    print "Ich bin spam."

Und wieder die Frage, was passiert, wenn man den Code ausführt?

>>> def decorator_for(name):
...     """Ich bin eine Factory und ich gebe einen Dekorator zurück."""
...     print "Erzeuge einen Dekorator für", name
...     # Den eigentlichen Dekorator (aus dem vorigen Beispiel) zurück geben
...     return decorator
...
>>> @decorator_for("Csaba")
... def spam():
...     print "Ich bin spam."
...
Erzeuge einen Dekorator für Csaba
Ich bin ein Dekorator und dekoriere spam

Und was passiert, wenn man die dekorierte Funktion ausführt?

>>> spam()
Ich bin spam.

Wie zu erwarten, noch immer nichts spektakuläres.

Wann wird ein Dekorator ausgeführt?

Der aufmerksame Leser kann sich diese Frage bereits selbst beantworten: Der Dekorator wird nicht etwa bei jedem Aufruf der dekorierten Funktion bzw. Methode aufgerufen, sondern genau ein einziges Mal, nämlich dann, wenn die Funktion bzw. Methode deklariert wird.

Ich will aber, dass bei jedem Funktionsaufruf etwas passiert

Auch das kann sich der aufmerksame Leser bereits selber herleiten: Wie bereits erwähnt, wird der Rückgabewert des Dekorators an den Namen der Funktion gebunden, die dekoriert wird. Als Beispiel also jetzt ein Dekorator, der nicht explizit die dekorierte Funktion wieder zurückgibt.

def useless_decorator(func):
    return None
>>> @useless_decorator
... def spam():
...     print "Ich bin spam."
...
>>> spam()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: 'NoneType' object is not callable
>>> spam
>>>

Da der Dekorator None zurückgibt, wird auch None an den Namen der Funktion, also spam, gebunden und die ursprüngliche Funktion ging verloren.

Man kann jetzt natürlich nicht nur die Original-Funktion oder None zurück geben. Vielmehr kann man auch einen Wrapper zurück geben, der dann die ursprüngliche Funktion aufruft. Damit hat man dann das erreicht, was man wollte: Bei Jedem Funktionsaufruf soll etwas passieren.

def verbose_caller(func):
    print "Erzeuge einen Wrapper für die Funktion", func.__name__

    def wrapper():
        print "Rufe die Funktion", func.__name__, "auf"
        func()
    return wrapper
>>> @verbose_caller
... def spam():
...     print "Ich bin spam"
...
Erzeuge einen Wrapper für die Funktion spam
>>> spam()
Rufe die Funktion spam auf
Ich bin spam
>>> spam
<function wrapper at 0x7f8d95b3c758>

So gesehen ist der Dekorator in diesem Fall nichts anderes als eine Wrapper-Factory.

Da das immer noch ziemlich langweilig ist, wollen wir uns jetzt einen personalisierten Wrapper erzeugen. Dazu bauen wir eine Wrapper-Factory-Factory:

def verbose_caller_for(name):
   print "Erzeuge eine Wrapper-Factory für", name

   def verbose_caller(func):
       print "Erzeuge einen Wrapper für die Funktion", func.__name__

       def wrapper():
           print "Rufe die Funktion", func.__name__, "für", name, "auf"
           func()
       return wrapper
   return verbose_caller
>>> @verbose_caller_for("Csaba")
... def spam():
...     print "Ich bin spam"
...
Erzeuge eine Wrapper-Factory für Csaba
Erzeuge einen Wrapper für die Funktion spam
>>> spam()
Rufe die Funktion spam für Csaba auf
Ich bin spam

Da das ganze langsam doch recht unübersichtlich wird, überlegen wir uns als gute Entwickler, wie man das ganze verschönern könnte.

Klassenbasierte Dekoratoren

Dekoratoren sind einfach Callables, die das zu dekorierende Objekt entgegen nehmen. Instanzen von Klassen können jedoch ein Callable implementieren, über die spezielle Methode __call__. Warum also nicht einen Dekorator über eine Klasse implementieren? Als passionierte Java-Entwickler wissen wir, dass Klassen alles übersichtlicher machen.

class PersonalizedVerboseCaller(object):
    def __init__(self, name):
        self.name = name

    def __call__(self, func):
        return self.decorate(func)

    def decorate(self, func):
        """Wrapper factory."""
        print "Erzeuge einen Wrapper für die Funktion", func.__name__
        def wrapper():
            print "Rufe die Funktion", func.__name__, "für", self.name, "auf"
            func()
        return wrapper
>>> @PersonalizedVerboseCaller("Csaba")
... def spam():
...     print "Ich bin spam"
...
Erzeuge einen Wrapper für die Funktion spam
>>> spam()
Rufe die Funktion spam für Csaba auf
Ich bin spam

Sun 27 October 2013

Wie Peter den deutschen Mittelstand rettet

Das ist Peter[*]. Peter arbeitet beim "Zentrum für Cyber Defence". Das "Zentrum für Cyber Defence" hilft, den deutschen Mittelstand vor Industriespionage zu schützen.

Wie er das tut, wird eindrucksvoll in einer (Kurz-)Reportage des br gezeigt:

Da der Cyber aber ziemlich groß ist, kann man da leicht den Überblick verlieren. Dashboards to the rescue!

Damit man auch bei der Kaffeepause enorm wichtige Nachrichten nicht verpasst (für den unwahrscheinlichen Fall, dass in der Cafeteria kein riesiger Monitor mit dem CND Radar hängt), gibt es das ganze auch als praktische Smartphone-App.

Auch vor Deep Packet Inspection macht die Cyber-Defence-Forschung keinen Halt:

Diese sieben Minuten sollte sich jeder Zeit nehmen, um Steuergeldern beim Verbrennen zuzusehen. Daher hier noch einmal der Link zur Dokumentation.

[*]Name von der Redaktion geändert

Mon 26 August 2013

Blogneustart - Versuch drei

Nach langer Zeit der Abstinenz, unter anderem ausgelöst durch den Plattentod des Blog-Hosts, habe ich beschlossen mal wieder ein wenig zu bloggen. Wie sich das gehört habe ich also als erstes einmal den kompletten Blog umgebaut.

Was hat sich geändert?

Das Aussehen! Und mit dem Aussehen auch die verwendete Blogsoftware. Nach Drupal und schrift ist jetzt Pelican an der Reihe. Zum ersten Mal habe ich das Theme komplett alleine erstellt, mit der Hilfe von Bootstrap.

Was ist gleich geblieben?

  • Für den geneigten Leser sichtbar: Es gibt noch immer keine Kommentare. Wer das Bedürfnis hat, einen Beitrag zu kommentieren oder mir einfach so etwas mitzuteilen, mag mir bitte eine E-Mail schreiben. Meine E-Mail-Adresse kann man auf der About-Seite finden.
  • Nicht so sichtbar: Der Inhalt wird noch immer aus reStructuredText erstellt.
  • Ich habe mich bemüht, dass meine alten Beiträge erhalten bleiben. Es gibt auch einige neue öffentliche Einträge, die ich aus dem nicht-öffentlichen Archiv ausgegraben habe. Die URLs zu den einzelnen Einträgen haben sich geändert, da muss ich noch überlegen, ob es mir die Mühe wert ist, dass die alten URLs noch gehen. Da der Blog aber eine ganze Weile nicht verfügbar war und sich niemand beschwert hat, glaube ich fast nicht, dass das passieren wird.

Wird es hier in Zukunft wieder regelmäßig Inhalte geben?

Das weiß ich ehrlich gesagt noch nicht. So manchen kleinen Blogeintrag, den ich hier früher verfasst habe, würde ich heute einfach auf G+ posten. Wir werden sehen. Vorgenommen habe ich es mir jedenfalls. Ihr könnt ja den Feed mal in euren Google-Reader-Ersatz aufnehmen.