Olivers Blog

Machine Learning mit Smile

2016-09-20T11:21:00+02:00

Wir beginnen mit einem leeren Java-Projekt. Für die Klassifikation werden wir eine Support Vector Machine (SVM) aus dem Smile framework benutzen.
Dafür laden wir zunächst die smile-core Komponenten herunter. Dies kann man ganz einfach über maven machen:

<dependencies>
    <dependency>
        <groupId>com.github.haifengl</groupId>
        <artifactId>smile-core</artifactId>
        <version>1.2.0</version>
    </dependency>
</dependencies>

Wenn man maven nicht mag, kann man sich die jars auch einzeln besorgen. Wir werden folgende jars benötigen:

Trainingsdaten

Als Trainingsdaten nehmen wir das wine-Datenset aus dem UCI Machine Learning Repository: Wine-Daten. Dieses Datenset enthält Informationen von Weinen, die alle in der gleichen Region in Italien gewachsen sind, jedoch von drei verschiedenen Rebsorten abstammen. Die Daten liegen im CSV-Format vor und enthalten als ersten Wert die Klasse (sozusagen die Rebsorte) des jeweiligen Beispiels. Die restlichen 13 Werte sind Werte aus einer chemischen Analyse der Weine. Unser Klassifikator soll nun anhand der Features vorhersagen, welche Rebsorte der jeweilige Wein hat.

Einlesen der Daten

Die Klassifikatoren in Smile haben alle ein ähnliches Eingabeformat. Wir benötigen die Klassen als Integer und die Features als double-Array. Da wir (normalerweise) vorher nicht wissen, wie viele Beispiele wir haben, bietet sich hier eine Liste an, die später in ein Array umgewandelt wird:

List<Integer> classes = new ArrayList<>();
List<double[]> features = new ArrayList<>();

Die features unserer Weine lassen sich dann mit etwas Java 8 Syntax recht einfach auslesen:

try (Stream<String> stream = Files.lines(Paths.get("/some/path/to/wine.data"))) {
    stream.forEach((s) -> {
        String[] vals = s.split(",");
        classes.add(Integer.parseInt(vals[0])-1);
        double[] instanceFeatures = new double[vals.length-1];
        for(int i=1; i<vals.length;i++) {
            instanceFeatures[i-1] = Double.parseDouble(vals[i]);
        }
        features.add(instanceFeatures);
    });
}

Nun noch schnell in das gewünschte Input-Format unseres Classifiers umwandeln:

double[][] featureArray = features.stream().toArray(double[][]::new);
int[] classArray = classes.stream().mapToInt(i->i).toArray();

Klassifikation

Die eigentliche Klassifikation geht dann wenn man die Features erst mal hat dank des frameworks recht leicht von der Hand. Da wir direkt eine Cross-Validation durchführen wollen, benötigen wir einen ClassifierTrainer, der die SVMs für die Cross-Validation trainiert:

ClassifierTrainer<double[]> trainer = new SVM.Trainer<>(new GaussianKernel(3), 10, 3, Multiclass.ONE_VS_ALL);

Da unsere Daten drei Klassen enthalten, müssen wir eine MultiClass SVM benutzen. Ich habe mich hier für die Variante one vs all entschieden, da diese schneller klassifiziert (weniger Durchgänge als bei one vs one).
Damit wir bei unserer Cross-Validation auch Ergebnisse sehen, müssen wir ein array aus ClassificationMeasure-Instanzen erstellen. Dieses wird dann an die Cross-Validation Methode als Parameter übergeben:

ClassificationMeasure[] measures = new ClassificationMeasure[]{new Accuracy(), new Precision(), new Recall(), new Fallout(), new FMeasure()};
double[] results = Validation.cv(10, trainer, featureArray, classArray, measures);
for(int i=0;i<results.length;i++) {
    System.out.println(measures[i].getClass().getSimpleName() + ": " + results[i]);
}

Und schon haben wir klassifiziert! Die Ergebnisse sind allerdings recht ernüchternd:

Accuracy: 0.398876404494382
Precision: 0.398876404494382
Recall: 1.0
Fallout: 1.0
FMeasure: 0.570281124497992

Normalisierung

Das liegt daran, dass wir vergessen haben zu normalisieren. SVMs (und auch einige andere Klassifikatoren), erwarten Werte im Intervall [0;1]. Wir normalisieren allerdings nicht hart in dieses Intervall, sondern wählen eine andere Variante der Normalisierung:
Wir ziehen von jedem Feature den Mittelwert ab und teilen dann durch die Standardabweichung. Das Ganze muss per Feature geschehen, über alle Instanzen hinweg. Hier der Code:

//berechnen der Mittelwerte
double[] means = new double[13];

for(double[] fInstance : features) {
    for(int i=0;i<fInstance.length;i++) {
        means[i] += fInstance[i];
    }
}
for(int i=0;i<means.length;i++) {
    means[i] = means[i] / features.size();
}

//berechnen der Varianzen
double[] variances = new double[13];
for(double[] fInstance : features) {
    for(int i=0;i<fInstance.length;i++) {
        variances[i] += Math.pow(fInstance[i]-means[i], 2);
    }
}
for(int i=0;i<variances.length;i++) {
    variances[i] = variances[i] / features.size();
}

//die eigentliche Normalisierung
double[][] featureArray = new double[features.size()][];
for(int i=0;i<features.size();i++) {
    double[] toNormalize = features.get(i);
    double[] normalized = new double[features.get(i).length];
    for(int k=0;k<features.get(i).length;k++) {
        normalized[k] = (toNormalize[k]-means[k])/Math.sqrt(variances[k]);
    }
    featureArray[i] = normalized;
}

Hier gibt es elegantere Möglichkeiten zur Berechnung, im Sinne der Verständlichkeit habe ich hier aber einfach die Schulformeln im Code umgesetzt.

Mit den normalisierten Werten sind die Ergebnisse nun um einiges erbaulicher:

Accuracy: 0.9887640449438202
Precision: 0.9859154929577465
Recall: 0.9859154929577465
Fallout: 0.009345794392523366
FMeasure: 0.9859154929577465

Kernel und Parameter

Damit eine SVM im realen Einsatz gute Ergebnisse liefert, müssen immer der Parameter C und die jeweiligen Parameter im Kernel optimiert werden. Das geschieht meist durch ausprobieren in 10er-Potenzen (also z.B. 0.001->0.01->0.1->1->10->100).
Der meist genutzte Kernel ist hier sicher der Gauß-Kernel, den wir auch oben benutzt haben. Ein linearer Kernel bietet jedoch den Vorteil, dass man leichter (bzw. überhaupt) visualisieren kann was gelernt wurde.

Die optimierte SVM trainieren und ausliefern

Wenn alle Parameter optimiert und wir mit den Ergebnissen zufrieden sind, wird es Zeit die SVM auf allen Trainingsdaten zu trainieren und auszuliefern. Dafür benutzen wir nun direkt die Klasse SVM:

SVM<double[]> svm = new SVM<>(new GaussianKernel(3), 10, 3, Multiclass.ONE_VS_ALL);

Als Parameter nehmen wir hier natürlich die vorher optimierten Werte. Trainiert wird die SVM dann folgendermaßen:

svm.learn(featureArray, classArray);

Dieses Objekt kann man dann serialisieren (z.B. mit xstream oder Gson), und später wieder einlesen.
Wenn man das SVM-Objekt dann erst mal hat, kann man mit ihm Vorhersagen für andere Datensätze treffen. Die Datensätze, für die die Klasse dann vorhergesagt werden soll, müssen vorher auf jeden Fall mit den gleichen Werten normalisiert werden, mit denen auch die Trainingsdaten normalisiert wurden:

double[] newExample = new double[]{12.77,2.39,2.28,19.5,86,1.39,.51,.48,.64,9.899999,.57,1.63,470};
for(int k=0;k<newExample.length;k++) {
    newExample[k] = (newExample[k]-means[k])/Math.sqrt(variances[k]);
}
svm.predict(newExample); //Ergebnis: 2

Die Werte für die Mittelwerte und die Varianzen sollten also gemeinsam mit dem SVM-Objekt serialisiert werden.

Postgresql json_agg (Web-App Serie)

2016-08-10T19:18:00+02:00

Als ich eine der SQL-Queries für das e-learning Portal geschrieben habe, kam darin auch ein JOIN-Statement vor. Ich habe mich also innerlich auf das 'manuelle' zusammenfassen der Ergebnisse im Code mittels einer map[string]string vorbereitet, da ist mir durch Zufall die postgresql json_agg aggregate function begegnet (postgresql aggregate functions). Die query würde dann folgendermaßen aussehen:

SELECT units.*, json_agg(pages.page_id) AS pages_arr FROM units LEFT OUTER JOIN pages ON ... GROUP BY units.unit_id

Der pages_arr-Wert wird dann als JSON-Array zurückgeliefert, das einfach mit einem beliebigen JSON-Parser in der jeweiligen Programmiersprache in ein Array oder eine Liste verwandelt werden kann.
Sehr praktisch wie ich finde!

Neue Serie: Web-App mit go/REST/postgres/JWT/emberjs

2016-08-10T17:58:00+02:00

Für ein Uni-Projekt habe ich die Aufgabe, eine E-Learning Applikation zu entwerfen. Diese soll zunächst als Web-App realisiert werden, die Möglichkeit native Apps für mobile Endgeräte nachzuentwickeln, soll allerdings auch vorhanden sein.

Für diese Anforderungen eignet sich ganz besonders die Kombination (REST)-api im backend und JavaScript MVC Framework für das frontend. Da ich normalerweise Web-Anwendungen mit Java/MySQL/JSF entwickle, wäre zumindest schon mal das frontend neu für mich gewesen. Um das Ganze noch interessanter zu machen, habe ich zusätzlich noch die Programmiersprache im Backend und die Datenbank geändert.

Als Programmiersprache für das backend werde ich go von Google benutzen und als Datenbank postgresql. Interessant an go ist vor allem die Art des deployens: Es wird eine komplett eigenständige binary mit Runtime und Garbage Collector erstellt. Beim jetzigen Projektstand ist diese lediglich 7,3MB groß (kompiliert mit go 1.7rc6). Es gibt noch viele weitere Dinge, die go anders macht als andere Programmiersprachen, doch für mich ist dies der interessanteste Unterschied zu Java, wo die "fat-WARs" schon mal 30-40 MB groß sein können mit allen Abhängigkeiten.

Für das frontend habe ich mich zunächst für emberjs entschieden. Da ich noch nicht mit der frontend-Entwicklung begonnen habe, kann ich hierzu noch nicht so viel schreiben, außer dass mir die Tutorials besser gefallen haben als die von Angular. Bei emberjs scheint mir alles etwas klarer und die Struktur der Applikation mehr vorgegeben zu sein.

Die Blog-Serie soll keine minutiöse Beschreibung der Entwicklung werden, sondern vielmehr interessante Entdeckungen und Entscheidungen festhalten.

JavaFX SceneBuilder unter Debian Jessie

2015-07-06T10:25:00+02:00

Da ich Swing etwas hässlich finde und eclipse RCP Projekte den Hang haben, bei der Auslieferung etwas riesige Dateigrößen anzunehmen, wollte ich mich mit JavaFX beschäftigen.

Lange Zeit war das etwas schwierig, da JavaFX im openjdk von Debian und Ubuntu (zumindest hieß es das, ich habe es damals nicht überprüft) nicht enthalten war. Jetzt hat sich die Lage etwas geändert. Für Debian Jessie gibt es in den Backports sowohl Pakete für openjdk8 als auch für openjfx. Zuerst müssen diese also installiert werden:

echo "deb http://http.debian.net/debian jessie-backports main" >> /etc/apt/sources.list
apt-get update
apt-get -t jessie-backports install openjdk-8-jdk openjfx

Leider ist in dem openjfx Paket der SceneBuilder nicht enthalten und auch Oracle liefert keine binaries mehr aus. Zum Glück gibt es aber andere nette Menschen, die einem die Arbeit abnehmen und den Code compilieren. Bei Gluon kann man sich die Binaries downloaden.

Ich habe mich hier für die executable jar entschieden, da mir der Unterschied von 2,6 MB für die jar zu den 44,9 MB für die .deb doch etwas heftig erschien. Um diese dann mit e(fx)clipse benutzen zu können, muss noch ein kleines wrapper-script angelegt werden:

cp Downloads/SceneBuilder-8.0.0.jar /usr/lib/jvm/java-8-openjdk-amd64/
echo "java -jar /usr/lib/jvm/java-8-openjdk-amd64/SceneBuilder-8.0.0.jar \$1" > /usr/local/bin/fxscenebuilder
chmod +x /usr/local/bin/fxscenebuilder

Damit kann man dann in eclipse in den Einstellungen für die SceneBuilder executable den Pfad "/usr/local/bin/fxscenebuilder" angeben.

Dolphin Emulator in Debian Jessie kompilieren

2015-04-04T14:17:00+02:00

Auf der Dolphin-Website gibt es zwar Pakete für Linux, allerdings sind diese für Ubuntu gebaut worden und in debian jessie kann eine Abhängigkeit (libpulse0) nicht erfüllt werden, weshalb die Pakete die Installation verweigern.

Da auch im Wiki die Beschreibung zum kompilieren (bzw. die Paketlisten) auf Ubuntu zugeschnitten sind, musste ich etwas länger suchen, um die richtigen Abhängigkeiten zu finden. Fündig wurde ich dann auf github. Hier nun also die Schritte für debian:

Zunächst benötigen wir git, um den sourcecode von github zu laden:

apt-get install git
git clone https://github.com/dolphin-emu/dolphin.git

Die Abhängigkeiten (mit pulse-audio als sound-backend):

apt-get install cmake g++ libwxbase3.0-dev libwxgtk3.0-dev libgtk2.0-dev libbluetooth-dev libxrandr-dev libxext-dev libreadline-dev libpulse-dev libusb-1.0-0-dev

Dann in das source-Verzeichnis wechseln, den Build-Ordner erstellen, in ihn wechseln, mit cmake konfigurieren und mit make kompilieren:

cd dolphin
mkdir Build && cd Build
cmake ..
make

Dann noch als root:

make install

LilyPond "Wiederholung unter der Klammer"

2015-01-25T09:51:00+01:00

In LilyPond sieht die Syntax für Wiederholungen mit den bekannten "Klammern" oder auch "Kästen" so aus:

\repeat volta 2 { music } \alternative { {music-1} {music-2} } music

Daraus wird dann dank LilyPond lesbare Musik:

Jetzt brauchte ich aber unter der Klammer 2 ein Wiederholungszeichen. Wie man das mit LilyPond umsetzen kann, hat sich mir nicht gleich erschlossen. Nach einiger Rumprobiererei und ergebnislosen google-Suchen habe ich dann kurz selbst nachgedacht und bin auf die Lösung gekommen. Die gesamte Klammer 2 muss die zu wiederholende Musik sein. Also so etwas:

\repeat volta 2 { music } \alternative { {music-1} {\repeat volta 2 { music-2 music }} }

Mit diesem Pattern kommt man zu folgendem Ergebnis:

Hier geht die Klammer über alle Takte. Bei zwei Takten ist das noch nicht so schlimm, aber wenn es mehr Takte werden ist das für den Musiker schon verwirrend und sieht auch nicht schön aus. Zum Glück kann man aber LilyPond mitteilen wie lang die Klammern sein sollen. Damit ergibt sich dies:

\repeat volta 2 { music } \alternative { {music-1} {\set Score.voltaSpannerDuration = #(ly:make-moment 2/2) \repeat volta 2 { music-2 music }} }

Und damit wird dann auch das gewünschte Notenbild gezeichnet:

Java substring() Performance

2014-12-21T00:05:00+01:00

Für ein aktuelles Projekt betrachte ich eine Textdatei mit einem "moving window". Ich betrachte also immer einen String mit fester Größe, den ich über die Datei wandern lasse. Auf diesen wende ich dann bestimmte Methoden an, um so Daten zu extrahieren. Meine erste Herangehensweise war, das ganze mit einem StringBuilder zu lösen, also die Datei byte für byte einzulesen und dann jeweils an der ersten Stelle einen char zu löschen. Das ganze sah dann folgendermaßen aus:

StringBuilder sb = new StringBuilder();
FileChannel fc = null;
try (RandomAccessFile raf = new RandomAccessFile(file, "r")) {
    fc = raf.getChannel();
    long fileSize = fc.size();
    ByteBuffer buf = ByteBuffer.allocate((int) fileSize);
    fc.read(buf);
    buf.flip();
    for (int i = 0; i < fileSize; i+=5) {
        sb.append((char) buf.get());
        if(i>windowSize) {
            sb.delete(0, 1);
        }
        if(i >= windowSize) {
            retVal =  retVal | FileReader.recognizeWithAll(retVal, sb.toString());
        }
    }
} catch (FileNotFoundException e) {
    //...

Diese Lösung hat schon einiges an Performance-Potential, das mir aber auf den ersten Blick nicht aufgefallen beziehungsweise egal war.

Mit dieser Implementierung brauchte mein Rechner für die 24.000 zu bearbeitenden Dateien über eine Stunde. Als mir das zu lang gedauert hat, habe ich einfach parallelisiert und auf 3 Kernen waren es auch nur noch 20 Minuten.

Dann kam allerdings das Problem auf, dass es für manche "Recognizer" praktisch wäre, das Fenster zu vergrößern und nach vorne oder hinten weiter zu suchen, wenn das Ausgangsfenster schon verdächtig schien. Ich habe das Codestück von oben durch dieses ersetzt:

int retVal = 0;
String longString = new String(Files.readAllBytes(Paths.get(file)), Charset.defaultCharset());
int i=0;
if(longString.length() >= windowSize) {
    for(i=0; i<longString.length()-windowSize; i+=5) {
        retVal |= FileReader.recognizeWithAll(retVal, longString, i, i+windowSize);
    }
    if(i!= longString.length()-windowSize) {
        retVal |= FileReader.recognizeWithAll(retVal, longString, longString.length()-windowSize, longString.length());
    }
} else {
    retVal |= FileReader.recognizeWithAll(retVal, longString, i, longString.length());
}

Ich habe also die ganze Datei in einen String eingelesen und dann mit den "Koordinaten" für das Fenster an die Recognizer geschickt. Die Signatur der Recognizer hat sich dabei auch geändert. Die Methoden sahen dann ungefähr so aus:

public int recognize(int retVal, String longString, int start, int end) {
    String recognizeString = longString.substring(start, end);
    //other code...
    return retVal;
}

Nachdem dies implementiert war, dachte ich mir, dass das ja vielleicht auch die Laufzeit kürzer werden müsste, da ich bei dem sb.delete() ein umkopieren des gesamten internen Arrays vermutet habe. Die Ernüchterung kam aber schon beim ersten Durchlauf: Es dauerte ähnlich lang mit dieser Implementierung. Also habe ich mir den StringBuilder-Sourcecode angeschaut. Doch die Vermutung mit dem umkopieren wurde bestätigt:

public AbstractStringBuilder delete(int start, int end) {
    //checks...
    int len = end - start;
    if (len > 0) {
    System.arraycopy(value, start+len, value, start, count-end);
         count -= len;
    }
    return this;
    }

Es wird also (fast) das ganze interne Array kopiert. Mit der neuen Implementierung sollte das eigentlich nicht geschehen. Wo war also das Problem? Der einzige Punkt, an dem etwas schiefgehen könnte, wäre die substring()-Methode. Also auch hier in den Sourcecode geschaut und in den Zeilen 1913 und 1914 wird nach ein paar checks ein String-Konstruktor aufgerufen:

return ((beginIndex == 0) && (endIndex == value.length)) ? this
                : new String(value, beginIndex, subLen);

Der Konstruktor tut nun folgendes:

public String(char value[], int offset, int count) {
    //checks...
    this.value = Arrays.copyOfRange(value, offset, offset+count);
}

Es wird also wieder das ganze Array kopiert! Als ich schon fast anfangen wollte, das ganze noch einmal in C oder C++ zu implementieren, fiel mir auf, dass die Methdoen in den Recognizern eigentlich keine Strings, sondern nur eine CharSequence als Eingabe benötigen. Lange Rede, kurzer Sinn: Hier ist meine eigene Implementierung von CharSequence ohne Array-Kopiererei.

public class MyCharSequence implements CharSequence {

    private String str;
    private int offset;
    private int end;

    public MyCharSequence(String str, int offset, int end) {
        super();
        if (offset < 0) {
            throw new StringIndexOutOfBoundsException(offset);
        }
        if (end - offset < 0) {
            throw new StringIndexOutOfBoundsException(end - offset);
        }
        if(str.length() - end < 0) {
            throw new StringIndexOutOfBoundsException(end);
        }
        this.str = str;
        this.offset = offset;
        this.end = end;
    }

    @Override
    public char charAt(int index) {
        if(index < 0) {
            throw new StringIndexOutOfBoundsException(index);
        }
        index += offset;
        if (index >= end) {
            throw new StringIndexOutOfBoundsException(index - offset);
        }
        return str.charAt(index);
    }

    @Override
    public int length() {
        return end - offset;
    }

    @Override
    public CharSequence subSequence(int start, int end) {
        if (start < 0) {
            throw new StringIndexOutOfBoundsException(start);
        }
        if (end > length()) {
            throw new StringIndexOutOfBoundsException(end);
        }
        return new MyCharSequence(str, start + offset, end + offset);
    }

    @Override
    public String toString() {
        StringBuilder sb = new StringBuilder();
        for(int i = offset; i<end; i++) {
            sb.append(str.charAt(i));
        }
        return sb.toString();
    }

    public void setEnd(int end) {
        if (end - offset < 0) {
            throw new StringIndexOutOfBoundsException(end - offset);
        }
        if(str.length() - end < 0) {
            throw new StringIndexOutOfBoundsException(end);
        }
        this.end = end;
    }
}

Dann noch folgendes ändern:

public int recognize(int retVal, String longString, int start, int end) {
    String recognizeString = new MyCharSequence(longString, start, end);
    //other code...
    return retVal;
}

Und schon war die Laufzeit bei 5 Minuten!

lftp und SSL

2014-12-20T21:40:00+01:00

Nachdem ich nun meinen Blog mit pelican erstellt hatte, wollte ich ihn auch möglichst ohne viele Probleme auf den Server bekommen. Dafür legt pelican beim quickstart ein Beispiel-Makefile an, in dem ein paar Möglichkeiten vorkonfiguriert sind. So zum Beispiel ssh_upload, rsync_upload und auch dropbox_upload. Da ich aber weder rsync noch ssh Zugriff habe und auch keinen DropBox Account, war für mich der ftp_upload interessant.

Hier legt das script dann folgende Zeile an:

lftp ftp://$(FTP_USER)@$(FTP_HOST) -e "mirror -R $(OUTPUTDIR) $(FTP_TARGET_DIR) ; quit"

Es wird also auf den Server gespiegelt. Dabei wird allerdings weder die Verschlüsselung der Daten, noch die Verschlüsselung der Login-Daten erzwungen. Ein Austausch des ftp mit einem ftps brachte nur no connection Fehlermeldungen mit immer länger werdenden timeouts hervor. Ein Blick ins manual kann da allerdings Wunder wirken. Hier ein Auszug:

ftp:ssl-force (boolean)
    if  true,  refuse to send password in clear when server does not
    support SSL.  Default is false.

Daraus ergibt sich dann folgender Befehl:

lftp ftp://$(FTP_USER)@$(FTP_HOST) -e "set ftp:ssl-force true; mirror -R $(OUTPUTDIR) $(FTP_TARGET_DIR) ; quit"

Jetzt wird die Übertragung der Login-Daten zwingend verschlüsselt. Wenn man noch mehr Privatsphäre will, kann man zusätzlich ftp:ssl-protect-data auf true setzen, dann werden auch alle Daten verschlüsselt. Für einen öffentlichen Blog halte ich das jedoch nicht für notwendig.

Erster Post

2014-09-03T17:18:00+02:00

In meinem ersten Blogeintrag soll es um die Erstellung desselbigen gehen. Nachdem ich einen Artikel auf Pro-Linux über pelican gelesen habe, war für mich klar, dass es das ist, was ich lange gesucht hatte. Die Gründe dafür werde ich hier kurz aufführen.

Was ist pelican?

Zunächst einmal sollte erklärt werden, was pelican überhaupt ist. Pelican ist eine Software, mit der sich statische blogs erstellen lassen. "Statisch" bedeutet hier, dass auf dem Server kein Programm ausgeführt wird, es liegen hier nur die *.html, *.css und *.js Dateien, die der Browser dann anzeigt.

Gründe die für pelican sprechen

Dies hat einige Vorteile. Zum einen braucht man keine Datenbank, um irgendwelche Dinge zu speichern und zum anderen kein php oder anders geartete Programme, die auf dem Server ausgeführt werden müssen. Es reicht ein Webserver wie Apache2, nginx oder auch lighttpd.Dadurch wird der Server geschont und kann auch mit weniger Rechenpower mehr Anfragen behandeln. Außerdem ist man auch sicherer vor Angriffen wie SQL-Injects oder anderen Lücken in der Blog-Software oder dem CMS. Der einzige Angriffspunkt ist hier dann noch der Webserver selbst.

Das war dann schon der erste Grund für meine Wahl von pelican. Der nächste Grund ist, dass die Artikel nicht in einem "What-You-See-Is-What-You-Get"-Editor geschrieben, sondern in StructuredText oder MarkDown Syntax verfasst werden. Da es in WYSIWYG-Editoren für html immer Probleme gibt bzw nachher doch alles anders aussieht, ziehe ich MarkDown ganz klar vor. Hier kann inline html geschrieben werden, sobald es nötig wird und ich habe das Gefühl, mehr Kontrolle über die Dinge zu haben. Außerdem entspricht der gesamte Workflow mehr dem von mir als Softwareentwickler.