Willkommen

DynamicFiles ist meine Projekt- und Portfolio-Seite zur Präsentation der eigenen Entwicklungsfähigkeiten und als zukünftige Referenz zur Selbstdarstellung.

Aktueller Blogeintrag

JavaFX-Gradle-Plugin, Statischen Website mit Gulp, Bower und Markdown

JavaFX-Gradle-Plugin

Eine JavaFX-Applikation mit Gradle zu generieren war bisher mit dem Gradle-Plugin "javafx-gradle" von Danno Ferrin möglich, da dieser jedoch das Projekt seit mehr als 18 Monaten nicht mehr weiterentwickelt hat, und auch seitens Oracle wohl unklare Policies herrscht, sammeln sich die Bug-Tickets auf BitBucket. Es herrschte somit ein ziemliches Ungleichgewicht zwischen der Maven- und der Gradle-Welt.

Da ich das JavaFX-Maven-Plugin jedoch jetzt knapp ein Jahr lang weiterentwickle, haben mindestens die Maven-Nutzer einen strategischen Vorteil gehabt und konnten hier auf eine einfache Konfiguration zur Generierung von Native-Bundles setzen. Dies ist jedoch vorbei, denn ich habe mit den Erfahrungen durch das Maven-Plugin ein eigenes Plugin für Gradle entwickelt.

Eins vorweg: ich bin kein Gradle-Nutzer, ich mag meine Lifecycles in Maven und die festen Strukturen und Abläufe. Wer lieber was eigenes haben will, darf ruhig Gradle verwenden ;) ich zwinge hier niemanden zu wählen! Das war auch der Grund wieso ich die Konfigurationsparamter nahezu identisch gehalten habe: bessere Migration von Maven nach Gradle und natürlich auch von Gradle nach Maven (ob es sowas wirklich gibt?!). Wer jetzt mit Gradle sein Buildscript um JavaFX-Fähigkeiten erweitern will, der kann dies ganz einfach durch mein JavaFX-Gradle-Plugin erreichen.

buildscript {
    dependencies {
        classpath "de.dynamicfiles.projects.gradle.plugins:javafx-gradle-plugin:1.0"
    }

    repositories {
        mavenCentral()
    }
}
apply plugin: "javafx-gradle-plugin"

Mehr dazu kann man auf Github finden.

Gulp und Co für statische Website-Generierung mit Sicherheit

Aber nicht nur da hat sich seit letztem Jahr etwas geändert, doch hier zuvor ein kleiner historischer Rückblick:
Zu Beginn meiner Website habe ich statisches HTML händisch getippt, damals waren Tabellen-Layouts gerade der Renner schlechthin, jeder im Web hat damit gearbeitet, weil die bisherigen Boxmodelle nicht vernünftig waren. Der große Nachteil daran: abgesehen davon, dass es kein semantisches HTML war, sollte auch heute offensichtlich sein, dass man zu viele Fehler macht, da man Dateien dupliziert. Eine Änderung an der HTML-Struktur und schon müssen auf einmal alle vorhandenen Seiten händisch neu angefasst werden (und wehe dem, dass man was vergisst oder sich vertippt).

Danach der erste Berühungspunkt mit PHP, sehr viel habe ich da über die Materie der dynamischen Websites gelernt und mir auch erarbeitet. Später dann der Versuch mittels Java ein eigenes CMS zu entwickeln, der jedoch eher in ganz viel KnowHow-Aufbau geendet ist anstatt dass etwas wirklich produktives dabei herausgekommen war.

Meine Website wird vollständig mit Gulp generiert! Angefangen hat dies mit einem Experiment, um mal mit "state-of-the-art" Technologie meine Website zu generieren. Das ganze läuft nun schon seit einigen Monaten und wurde von mir nach und nach ausgebaut. Aktuelles neue Feature: automatische Prüfsummen-Generierung für Subresource Integrity, und das ganz mit den Mitteln von NodeJS!

Hier ein kleiner Auszug aus meinem gulpfile:

function getSubressourceIntegrity(entry, printAsAttributeValue){
    var foundResourceHash = allChecksums[entry];
    printAsAttributeValue = printAsAttributeValue === true;
    if(foundResourceHash !== "" && typeof foundResourceHash !== "undefined"){
        if(!printAsAttributeValue){
            return "integrity=\"" + subresourceIntegrityHashMethod + "-" + foundResourceHash + "\" crossorigin=\"anonymous\"";
        }
        return subresourceIntegrityHashMethod + "-" + foundResourceHash;
    }
    return "";
}
// don't escape the output
getSubressourceIntegrity.safe = true;
swig.setFilter("getSubressourceIntegrity", getSubressourceIntegrity);

Für die Generierung der Prüfsumme läuft vorher ein Task, der alle generierten und kopierten Ressourcen filzt und sich in einem Javascript-Objekt merkt:

function calculateIntegrityHash(){
    return through.obj(function (file, encoding, callback) {
        if(file.isBuffer()) {
            var pathprefix = file.cwd + "/" + targetFolder;
            var fileName = file.base.substr(pathprefix.length) + file.relative;
            fileName = fileName.replace(/\\/g, "/");

            var someChecksum = crypto.createHash(subresourceIntegrityHashMethod).update(file.contents, "utf8").digest("base64");
            allChecksums[fileName] = someChecksum.substr(0,someChecksum.length - 1);
            console.log("generated checksum for", fileName, "with result: ", allChecksums[fileName]);
        }

        this.push(file);
        return callback();
    });
}

In meinen SWIG-Templates habe ich somit folgendes stehen:

<link rel="stylesheet" href="/style/mobile.css" data-enhanced-integrity="{{"/style/mobile.css"|getSubressourceIntegrity(true)}}" />
...
<script src="/script/jquery.min.js" defer {{"/script/jquery.min.js"|getSubressourceIntegrity}}></script>

Dadurch kann ich ohne nachträgliche Arbeit automatisch die entsprechenden Hashes generieren und einfügen. Diese Lösung hat zwar den Nachteil, dass ich hier meine Templates entsprechend anpassen muss, allerdings habe ich dann die volle Kontrolle, und muss nicht über einen nachträglich konstruierten DOM arbeiten.

Kleine Seitennotiz zur Sicherheit: ich habe aus meinen Social-Funktionen den REDDIT-Link entfernt, da diese seit diesem Jahr ihre AGB geändert haben. Auch wenn es darum geht, dass REDDIT Werbeeinnahmen generieren kann, so möchte ich alle Besucher nicht dem entsprechend bevormunden. Hierfür werde ich später noch eine Kleinigkeit in Richtung 2-Klick-Lösung bauen.

Die nächste Umstellung wird allerdings die Umsetzung der Blog-Einträge betreffen, damit diese auch einzelnd verlinkt werden können. Bisher sammeln sich alle Beiträge auf einer Jahres-Seite, allerdings ist das nicht so ganz sauber, wie es sich anfangs in meinem Kopf dargestellt hatte. Außerdem werde ich meine CSS-Dateien nochmal neu aufsetzen und mit SASS oder LESS bauen, bisher sind diese noch "Hand-gezupft".

Einige dieser Erfahrungen fließen direkt in meine alltäglich Arbeit ein, viele jedoch sind und bleiben mein eigenes Wissen, welches früher oder später dann doch seine Anwendung findet. Manches davon mag vielleicht unnützes Wissen sein, aber je mehr man sich davon aneignet (und es einen nicht belastet), desto vielfältiger kann man später über den Tellerrand blicken.

Und damit soll es dieses Mal auch belassen sein, viel Erfolg allen bei Ihrer Arbeit!

zu allen Blogbeiträgen von 2016

Portfolio

Aktuelle Projekte

Aktueller Arbeitgeber edicos Webservices GmbH

Teile diese Seite

work in progress