Unternehmer und Geek

Kategorie: Uncategorized

  • Static Site Generator – Was ist das?

    Moderne Webseiten sind Datenbankgetrieben!? Falsch. Moderne Webseiten sind Datengetrieben. Daten ungleich (!=) Datenbank. Ja, WordPress, Drupal, Joomla und Co. haben eine Datenbank als Herzstück. Bei jedem Seitenaufruf wird der Inhalt aus der Datenbank geholt, zusammengebaut und als HTML Datei dem Benutzer im Browser angezeigt. Dies bietet grösstmögliche Flexibilität fordert jedoch entsprechende Komplexität. Flexibilität welche nicht für jedes Projekt notwendig ist, Komplexität, welche nicht für jedermann erwünscht ist. Und ausserdem, die Seite wird alle paar Tage oder Wochen geändert, warum also die Rendering Arbeit jedes Mal aufs Neue machen?

    Statische Seiten – Wie alles begann

    Als damals in den 90er Jahren alles begann, gabs HTML und keine Javascript und kein PHP. Seiten wurden einzeln gebaut und publiziert. Strukturen wurden in Ordnern abgelegt, Redesigns wurden sehr aufwändig. Zwischen Inhalt und Design kab es keine Trennung, bis dass der Tod euch scheidet. Die statischen Seiten boten jedoch einen ausserordentlichen Vorteil:
    1. Grössmöchliche Flexibilität & Individualität (oder was halt damals möglich war)
    2. Straight forward, daher auch von einem nicht-Programmierer Wart- und Erweiterbar.

    Fleischwolf, rödel, rödel – Static Site Generator

    Einen Löffel Statische HTML Seiten mit einer Priese Datenbank ergibt Static Site Generator. Ein Static Site Generator, nimmt Dateien mit Text (als HTML oder Markdown) angereichert mit frei wählbaren Metadaten, setzt sie in ein Template und generiert daraus die Webseite. Je nach Site Generator, gibts Funktionen, um ein Pagination zu machen, Listen mit bestimmten Kategorien usw. Bei jeder Änderung wird die Seite neu generiert. Falls keine Änderungen gemacht werden, muss auch das HTML nicht aktualisiert werden.
    Static Site Generator

    Die Vorteile eines Static Site Generator

    Die Vorteile sind schnell aufgezählt:

    • Geschwindigkeit. Da lediglich ein Webserver vorhanden ist, welcher die fertig gerenderte HTML Seite ausliefert passiert das mit Lichtgeschwindigkeit. Es geht keine Zeit mit Datenbankabfragen verloren.
    • Einfachheit. Templates zu erstellen sind denkbar einfach. HTML erstellen, und Template Variablen für Text einsetzen. Je nach Fähigkeiten und Kenntnissen können mehr oder weniger komplexe Strukturen gebaut werden.
    • Sicherheit. Keine Passwörter, keine veraltete Versionen, einfach HTML.
    • Designerische Exzellent. Korrekte Wort? Mit wenig Aufwand sehr aufwändige und Ansprechende Designs gemacht werden. Wenn ein HTML Template vorhanden ist, ist der Schritt zum Template nur noch minimal.
    • Kosten. HTML Dateien können fast überall gehostet werden und die Preise dafür reichen von nichts bis sehr wenig: Dropbox, GoogleDrive und jeder beliebige Feld-, Wald- und Wiesenhoster.
    • Datenhoheit. Auch für technisch weniger versierte User sind die Daten sofort vorhanden. Diese müssen nämlich nicht mühsam aus einer Datenbank gepickt werden, sondern sie liegen als einfaches Markdown Dokument: Kopieren, löschen usw. ist ein Kinderspiel und ohne technische Kenntnisse möglich.

    Die Nachteile eines Static Site Generator

    Jede Medaille hat auch ihre Kehrseite:

    • Dynamischer Inhalt. Kommentare, Kontaktformulare bzw. benutzerspezifische Inhalte können nicht umgesetzt werden. Hier muss auf ein Drittsystem eingesetzt werden: Für Kommentare z.B. Disqus, für ein Kontaktformular Wufoo und auf benutzerspezifische Inhalte muss man verzichten. Dazu gehören auch jegliche andere «Mitmachfeatures», wie z.B. Forum, eCommerce, Gästebuch usw.: Mit einer statischen Seite nicht ohne weiteres Machbar.
    • Skalierbarkeit. Meine Grösste Seite bisher umfasst 600 Artikel. Seiten mit mehreren tausend Artikeln als Statische Seite zu gestalten macht wohl eher weniger Sinn, da das Verwalten dann relativ schwierig wird. Auch wird das Generieren der Seite mehr und mehr Zeit in Anspruch nehmen, je grösser die Seite ist.

    Kleine Liste an Static Site Generator

    Die Liste soll bei definitiv nicht abschliessend sein, aber doch mal einen Startpunkt geben.

    Und jetzt?

    Wie so oft: Es kommt drauf an. Eine Community Seite: Bitte Drupal. Ein Multiuser High Traffic Blog: WordPress (oder natürlich auch Drupal). Eine Portfolio Seite: Static Site Generator. Die Vereinsseite: Static Site Generator. Ein persönliches Blog: Static Site Generator. Ein ganz verrückte ausgefallene Seite: Static Site Generator.

  • Eine statische IP mit Amazon AWS Route53

    Seit Jahren nun benutze ich Dyndns, um zuhause auf meinen Server zugreifen zu können. Ich war jedoch zu geizig, um pro Member zu werden, damit ich Top Level Domains auf meine IP zeigen lassen kann (diese wechselt periodisch, daher brauche ich einen Dienst wie Dyndns). Mein Domain hiess dann jeweils etwas.mine.nu und zudem muss ich alle paar Wochen meinen Account mit einem Klick bestätigen… das geht besser: Amazon AWS Route53 und die API.

    Voraussetzungen für das AWS Route53 Script

    • (AWS Route53)[https://aws.amazon.com/route53/]
    • (node.js)[http://nodejs.org/] installiert
    • (AWS SDK for node.js)[https://aws.amazon.com/sdkfornodejs/]
    • Einen Cron Job

    Das Script funktioniert dann auch ganz einfach: die eigene IP holen, und dann via Amazon AWS SDK auf den AWS Route53 Server verbinden, bestehende IP Eintrag löschen und die neue IP eintragen. That’s it. Einfacher gehts kaum noch. Der Cronjob läuft 1x Stunde. Von daher ist bei einem Wechsel der IP eine maximale Downtime von 59 Minuten möglich… ist verkraftbar und sonst könnte ich immer noch den Cronjob regelmässiger laufen lassen.
    Script ist noch sehr rudimentär und hat sicher noch viel Potential in Punkte Schönheit und Eleganz. Es ist jedoch verständlich und funktioniert und liegt auf Github zum Forken bereit.
    Auch AWS Route53 ist mit minimalen Kosten verbunden. Diese belaufen sich auf 0.5 Cent pro Monat plus ein bisschen was für die Anzahl an requests.

  • Der perfekte Editor für Webdesigner/Entwickler

    Den perfekten Editor für Webdesigner/Entwickler gibt es nicht. Trotzdem wird immer wieder gefragt: "Welches ist der beste Editor für PHP Projekte": Die vergangenen zwei Tage gerade zwei solche Beiträge auf Google+ gesehen (und waren wahrscheinlich nicht die einzigen):

    Die Antworten sind dann auch immer entsprechend lang. Also laut den Antworten sind die folgenden Editoren sehr empfehlenswert (also sozusagen Developers choice):

    Eine ansehliche Auswahl und könnte unterschiedlicher nicht sein: Von den reinen Texteditoren, über Cloud Editoren hin zu vollwertigen Entwicklungsumgebungen mit Dreamweaver als WYSIWYG als I Tüpfelchen oben drauf. Wenigstens Frontpage hat niemand erwähnt (hätte wahrscheinlich vor 10 Jahren ganz anders ausgesehen).

    Und was sollen jetzt die beiden mit den Antworten machen? … Ausprobieren. Und das wäre dann auch meine kurze Antwort: Ausprobieren. Und die lange Antwort folgt jetzt: Es gibt drei Arten von Editor: Text Editor, IDE und WYSIWYG Editor.

    Sublime Text

    Text Editor

    Texteditoren sind sehr leichtgeweichtig. Jedes Betriebssystem kommt von Haus aus mit einem Text Editor, e.g. für Windows ist es Notepad. Mein ersten Javascript Erfahrungen vor ca. 15 Jahren habe ich mit Notepad gemacht, jedoch nicht nachahmenswert. Zu den besseren Texteditoren gehören Sublime Text, Notepad++ und Vim.

    Texteditoren sind vor allem bei Entwicklern von Scriptsprachen (sprich PHP, Javascript) sehr beliebt, doch auch Webdesigner meistens auf Text Editoren zurück, um HTML Code zu schreiben. Welches schlussendlich der Beste ist hängt vom Betriebssystem und den persönlichen Vorlieben ab.

    Mein persönlicher Favorit aktuell ist Sublime Text, aber ich habe auch lange mit Notepad++ gearbeitet

    Entwicklungsumgebung (IDE)

    Vom Editor zur IDE ist es ein grosser Sprung. Eine Idee ist oftmals mit Web Server, Testumgebung, Refactoring Tools, Debugging Möglichkeiten und irgendwelchen GUI Komponenten ausgestattet. Zu den bekanntesten gehören sicher PHP Eclipse, Netbeans oder auch PHPStorm.

    Ursprünglich kamen die IDEs von den "grossen" Sprachen wie Java und C++. Wer Java Programmiert hat, kam eigentlich kaum an Eclipse vorbei. Grosse Vorteile dieser IDEs waren unter anderem, dass sie Abhängigkeiten in Projekten erkannten und den Entwickler mit Code Completion unterstützten… (seeehr Hilfreich in der Java Welt). Finde Leute haben dann Plugins geschrieben und so ist PHP Eclipse entstanden, dann hat auch Zend mal etwas für PHP basierend auf Eclipse gemacht … langer Rede kurzer Sinn, mittlerweile sind IDEs auch für Skript Sprachen zu haben.

    Für wen sind IDEs? Hier wird definitiv der Entwickler angesprochen. Ein wenig Front-End Javascript zu schreiben… bitte nicht in einer IDE, dafür gibts leichtgewichtige (aber mächtige) Text Editoren.

    Frontpage

    WYSIWYG Editoren

    HTML Zeichnen: Der (Alp)Traum eines jeden Webdesigners. Ich würde diese Tools als IDE für Webdesigner bezeichnen: Graphische Werkzeuge, tausende von Funktionen und eingebauten Spezialitäten, mit dem Ziel, eine Webseite zu erstellen zu warten und zu publizieren.

    Microsoft Frontpage hat den furiosen Einstieg gemacht und wurde dafür von der Community gehasst. Der produzierte Markup war ein wahrer Alptraum (zugegeben, meine erste Webseite habe ich auch mit Frontpage Express gemacht). Dreamweaver wurde dann irgendwann zum Platzhirsch und ist es wahrscheinlich auch heute noch.

    Die einen lieben Dreamweaver aufgrund seiner visuellen Fähigkeiten, die anderen finden der integrierte Text Editor sei super. Einen WYSIWYG Editor empfehle ich vor allem HTML Neulingen und visuellen Leuten.

    An dieser Stelle sei angemerkt, dass es sehr ansprechende Online Dienst wie z.B. Webflow oder FROONT. Da ich selber wenig visuell arbeite, sondern hauptsächlich im Texteditor, fällt es mir schwer, hier ein Urteil zu fällen.

    Webflow Design Tool

    Fazit

    Ob WYSIWYG-, Text Editor oder IDE und vor allem WELCHER, hängt ganz davon ab, was machen machen will und viel wichtiger, den persönlichen Vorlieben. Daher wird man wohl kaum verschont bleiben, den einen oder anderen Editor mal auszuprobieren.

    Bezüglich WYSIWYG Editoren gibt es einen guten Artikel auf Smashing Magazin – 25 WYSIWYG Editors reviewed. Und hier wäre noch eine List von Text Editoren auf Wikipedia

  • Eigene Filter für Wintersmith mit Nunjucks

    Die Dokumentation für Wintersmith ist sehr bescheiden und in Deutsch mag das hier die einzige Anleitung sein, welche du überhaupt finden wirst. Daher nehme ich mir die paar Minuten, um das kurz zu dokumentieren.

    Grundlage für Wintersmith/Nunjucks Filter

    Folgende Voraussetzungen müssen gegeben sein:
    – Funktionierende Wintersmith Installation (dazu gehört auch Node.js)
    – Das Plugin Wintersmith darf nicht installiert sein
    – Via npm nunjucks installieren

    Jade oder Nunjucks

    Jade ist für mich ein No-go. Das sieht mir einfach zu kryptographisch aus. Es mag sicher Vorteile haben, doch ich habe mir noch nicht die Mühe genommen, mich da reinzulesen. Für mich persönlich ist eine Template Sprache in HTML. Daher ist die Wahl dann auch sehr schnell auf Nunjucks gefallen, da ich diese bereits von meinem kleinen Ausflug in die Django Welt kenne (dort heisst es halt Jinja).

    Beispiel eines Wintersmith/Nunjuck Filters

    Ich wollte einen Filter machen, welcher mir einen Teaser/Abstract aus dem Text extrahiert. Aufruf sollte wie folgt erfolgen:
    ~
    {{ page.html | makeAbstract(150) }}
    ~
    Wobei der Integer Wert die Anzahl Zeichen des Teasers angibt. Leider gibt es keinen entsprechenden Filter oder ich habe ihn grosszügigerweise übersehen.
    Mein erster Versuch war, ein neues Plugin zu schreiben, welches sich in das bestehende Wintersmith-Nunjucks Plugin einklinkt und dann den Filter hinzufügt. Leider klappt das so nicht. Man muss daher das Wintersmith Nunjucks Plugin anpassen:
    ~
    var nunjucks = require(«nunjucks»);
    module.exports = function(env, callback) {
    var NunjucksTemplate = function(template) {
    this.template = template;
    };
    NunjucksTemplate.prototype.render = function render(locals, callback) {
    try {
    callback(null, new Buffer(this.template.render(locals)));
    } catch (error) {
    callback(error);
    }
    };
    NunjucksTemplate.fromFile = function fromFile(filepath, callback) {
    var nenv = new nunjucks.Environment(new nunjucks.FileSystemLoader(env.templatesPath));

      var makeAbstractFilter = nenv.addFilter('makeAbstract', function(str, n) {
      if (str == undefined) {
          str = "";
      } 
      str = str.replace(/(<([^>]+)>)/ig,"");
    var tooLong = str.length>n;
    var s_ = tooLong ? str.substr(0, n-1) : str;
    s_ = tooLong ? s_.substr(0,s_.lastIndexOf(' ')) : s_;
    return  tooLong ? s_ + '&hellip;' : s_;
});

callback(null, new NunjucksTemplate(nenv.getTemplate(filepath.relative)));

    };

    env.registerTemplatePlugin(«*/.*(html)», NunjucksTemplate);
    callback();
    };
    ~
    Das ist der Code, welcher 1:1 vom Wintersmith-Nunjucks Plugin kopiert wurde, mit der Ausname der Funktion makeAbstractFilter. Die Funktion ist dann auch schon der Filter und somit ist das Problem gelöst. Das ganze in den Plugins speichern und die Config Datei entsprechend anpassen und schon ist das Problem gelöst.

  • Redesign von WordPress zu Jekyll nach Wintersmith

    Vor ca. 3 Monaten habe ich mein WordPress Blog durch Jekyll abgelöst und habe das Blog auf Github verschoben. Funktioniert eigentlich wunderbar, ausser dass mir Ruby nicht sehr sympathisch ist, bzw. ich keine Zeit und Lust habe mich mit Ruby zu beschäftigen, daher die Suche nach einem anderen Static Site Generator (SSG). Es gibt anscheinend solche in PHP, aber scheint irgendwie nicht zu passen und Java gibt es sicher auch, aber nein Danke und so landete ich bei Wintersmith (node.js basierend).

    Hosting & Publishing Architektur

    Github Pages basieren auf logischerweise auf Git. Es hat mich gestört, dass ich ständig das Gitrepository haben musste und auf Github zu edtieren ist zwar möglich aber nicht wirklich eine Freude. Manuell die Seite jedes mal zu builden schien mir auch zu kompliziert, daher die Idee des Dropbox Hostings. Der Workflow dazu sieht wie folgt aus:

    1. Neue Seite im Admin Interface erstellen. Das erstellt im verknüpften Dropbox Konto einen neuen Ordner.
    2. Wintersmith Seite in Dropbox anlegen.
    3. Seite wird auf meinen Server synchronisiert und dort als Wintersmith Projekt auf Webserver gebaut.
    4. Die aktuelle Dropbox API erlaubt lediglich ein Polling, daher wird im regelmässigen Zyklus nach Änderungen gepollt, alternativ kann ich auch übers Admin Interface manuell publizieren

    Als Webserver habe ich nginx. Ich habe mich seit einigen Monaten von Apache verabschiedet. Mir scheint nginx logischer und einfacher zu konfigurieren und hinzu kommt, dass er anscheinend schneller und weniger ressourcenhungrig zu sein scheint (das ist eine nicht fundierte Aussage). Es fehlt daher lediglich noch eine Regel, um subdomains automatisch auf einen Ordner zu mappen, also blog.rapsli.ch -> /vaw/www/public/blog und schon ist meine eigene Cloud ready. Die Konfiguration für nginx dafür sieht wie folgt aus (hier gefunden).

    server {  
    listen  80; 
    server_name   ~^(.*).nginxdomain.com$; 
    #if directory doesn't exist
    if (!-d /home/domains/nginxdomain.com/public/$1) {
        rewrite . http://www.nginxdomain.com/ redirect;
    }

    # Sets the correct root
    root /home/domains/nginxdomain.com/public/$1;
}

    Vorteile von Node.js

    Wie gesagt habe ich vorher mit Jekyll gearbeitet und ich muss sagen, der Build Prozess ist schleppend langsam. Mein Blog mit knapp 600 Einträgen hat doch eine gewisse Zeit gebraucht. Mit Node und Wintersmith geht das alles merklich schneller, doch das ist eigentlich nur der kleinere Teil der Erfolgsstory.
    Die asynchrone Natur von Node.js und die damit verbundenen Vorteile kommen in diesem Szenario richtig gut zur Geltung:

    • Polling der Dropbox API übers Netzt -> sehr langsam
    • Builden via Wintersmith -> auch nicht super schnell

    Im Normalfall, z.B. mit PHP, könnte das alles nur seriell abgearbeitet werden. Dank der Asynchronität von Node.js kann das jetzt alles parallel bearbeitet werden, was sich besonders im Zusammenspiel mit der Dropbox API positiv zeigt -> die meiste Zeit muss ja eh gewartet werden.

    Der Design Prozess

    Ich bin immer noch kein Designer, aber die aktuellen Tools (besonders die Grid Layouts) machen vieles einfacher. Des Weiteren ist man beim Design für einen Static Site Generator viel flexibler und schneller, da keine Datenbank und komplexe Logik dahinter steckt. Natürlich muss dadurch auch der eine oder andere Kompromiss eingegangen werden, doch dazu bin ich gerne bereit:

    1. Reines HTML Dokument anlegen
    2. Template in Hierarchie aufteilen
    3. Statischen Text durch Template Tags ersetzen

    Bei Schritt 1 ist lediglich HTML, CSS und Javascript vorhanden -> ultra performant und zackig.
    Zuerst habe ich mit dem Gedanken gespielt, irgend ein HTML Template zu nehmen, doch die Neugier mal wieder etwas komplett selber zu machen hat dann doch gesiegt. Da ich kein grosser Held mit Photoshop bin, wird es gezwungener Massen ein Design ohne viel Schnick Schnack und ohne aufwändige Grafiken, aber das auch auch irgendwie seinen Reiz.
    Das Grundgerüst steht aber es hat noch viele Lücken. Noch länger mit der Migration warten? Nein, wollte ich dann doch nicht. So habe ich jetzt das Redesign schon mal publiziert und werde dann über die Zeit die noch offenen Lücken stopfen.

    Responsive ist Pflicht

    Auch hier wieder: Grid Systems (Twitter Bootstrap) seid dank, ist das eigentlich nicht allzu aufwändig. Im Detail hat es noch Potential nach oben, aber kommt Zeit kommt Rat. So wird auch hier sicher noch der eine oder andere Fehler behoben.

    Migrations Beigemüse

    Die URL Struktur habe ich bei der Gelegenheit auch gleich mal angepasst. Diese war bisher: rapsli.ch/[titel] und ist jetzt neu blog.rapsli.ch/posts/[jahr]/[titel]. Damit nicht alle Links komplett kaputt gehen habe ich 600 rewrite rules gemacht, welche in der nginx Config liegen. Einzig die Migration der Kommentare habe ich leider noch verhauen, dabei wäre es so einfach gewesen, hätte ich nur 1 Minute länger gelesen, aber das kommt davon, wenn man morgens um 1 Uhr noch so etwas machen will.

    Offene Punkte

    Noch gibt es einige Dinge, welche ich zu erledigen habe:

    • Die Sache mit den Kategorien
    • Die Google Suche einbinden
    • Die Kommentarmigration noch retten (falls möglich) (Keine Lust dazu… tschüss Kommentare)
    • Design noch verfeinern
    • Den restlichen Inhalt noch einfügen
    • Sitemap erstellen

    Tools, welche ich verwende

    In meinem Workflow setze ich die folgenden Tools ein:

    • Dropbox
    • Writebox App, um von überall her Inhalt zu ändern
    • nginx als Webserver
    • Wintersmith als rendering Engine
    • Node.js als darunterliegende Technologie

    Alles in Allem: Sehr zufrieden und die darunter liegende Infrastruktur ist super! Falls du interesse hast, ein Alpha Tester zu sein, darfst du dich gerne mal bei mir melden.

  • Ein Blog mit Wintersmith

    Nachdem ich vor ein paar Monaten ein wenig mit Jekyll herumgespielt habe, habe ich jetzt noch eine Lösung basierend auf Node.js gesucht. Das ganze Ruby Zeugs kommt mir einfach ein wenig spanisch vor. In der Node Welt gibt es zwar ein paar Static Site Generators, aber keiner der so richtig heraussticht (wie das eben mit Jekyll der Fall ist). Ich habe mich für Wintersmith entschieden und bin eigentlich bisher damit ganz glücklich. Ist zwar in Coffee geschrieben, aber so ist es nun mal.

    Hier eine Liste mit Lessons Learned. Diese Liste werde ich über die Zeit erweitern.

    Jade Ade – Nunjucks Hello

    Sorry, Jade ist einfach unbrauchtbar als Templating Engine. Ich will HTML schreiben, weil HTML rauskommt und nicht irgend so ein Pseudo Markup. Nunjucks ist super und auch für Wintersmith vorhanden.

    Artikel Struktur

    Es scheint als müssten die Artikel nach folgendem Schema abgelegt werden:

    contents
    articles
        post1
            index.md
        post2
            index.md
          post3
            index.md

    Ich bin mir noch nicht sicher, ob mir das gefällt oder nicht und weiss auch noch nicht genau, wo man das anpassen kann.

    Update 26.08.2013: Stimmt nicht ganz. Das ist sicher die Struktur, wie sie ursprünglich mal angedacht worden ist und wie sie auch in vielen einfachen Beispielen benutzt wird. Es ist jedoch ohne weiteres Möglich eine beliebige Struktur zu nehmen, allerdings muss dann das Artikel Listing angepasst werden.

    Artikel Listings

    Es scheint als braucht man dafür ein Helper Plugin, welches ich mir von David Tucker abgeschaut habe. Das Repository ist Gold wert und hier werde ich sicher noch ein bisschen Zeit drin verlieren um zu lernen.

    Dieses Plugin funktioniert allerdings lediglich, wenn die Artikelstruktur wie oben abgebildet ist. Falls jedoch eine beliebige Struktur gewählt wird, dann muss das ein bisschen aufgebohrt werden. Dazu habe ich Davids Plugin ein bisschen gepimpt (sieht zwar nicht nicht mehr kurz und sexy aus, aber es funktioniert). Code ist hier im Gist vorhanden.

    Paginator

    Dafür gibts ein plugin, welches standardmässig mit dabei ist. Ich habe es jedoch noch nicht ausprobiert, bzw. mein Test hat dazu geführt, dass meine anderen Helferscripte nicht mehr gelaufen sind.

    Seite wird nicht gerendert

    Es gibt natürlich viele mögliche Fehlerquellen. Die einfachste wäre: Sichergestellt, dass ein Leerschlag in den Metainformationen jeweils zwischen Schlüssel und Wert ist? Zum Beispiel

    date:2013-08-22

    Das wird leider nicht rendern, sondern das müsste wie folgt ausschauen:

    date: 2013-08-22

    Allgemein ist der Header Teil eine Quelle für Fehler. Zwingend notwenig im Header ist jedoch nur Template (und nicht etwa layout, wie das by Jekyll der Fall ist)

    Wintersmith Community

    Ist leider noch relativ klein. Hier bedarf es noch ein wenig Arbeit, um gegen den Platzhirsch Jekyll anzukommen. Gute Ausgangspunkte sind aktuell lediglich die Wintersmith Github Seite plus den IRC Kanal (#wintersmith) -> aber bitte nicht zu viel Ansturm erwarten. Ein Forum oder eine Gruppe gibt es leider noch nicht… wäre aber dringend notwendig.

    Mehr wird sicher noch kommen

  • Node.js und asynchrone Module

    Hier die Ausgangslage:

    • Ein Module, welches einen Ordner auf Dropbox mit einem lokalen Ordner synchronisiert
    • Die App ist multi Mandantenfähig, sprich, es können Ordner von mehreren Dropboxen synchronisiert werden

    Und hier ist das geniale von Node.js, bzw. asynchroner Programmierung: Bei einem solchen Vorgang verbringt die App wohl die meiste Zeit mit warten: Dropbox Authentifizierung und Download der Daten ist nicht sehr rechenintensiv dafür sehr Zeitintensiv, wobei die meiste Zeit mit warten verbracht wird. Mit Node.js lässt sich das super einfach parallel abarbeiten, aber Vorsicht.

    Mein vereinfachtes Problem sieht wie folgt aus:

    // test.js
var name = "raphael";
exports.updateName = function(namein) {
    name = namein;
    setTimeout(function(){console.log("my name is: " + name)}, 1000);
}

// app.js
names = ["Annika", "linea", "nele"];
names.forEach(function(name){
    var namer = require('test');
    namer.updateName(name);
});

    Was ist wohl das Resultat davon?

    nele
nele
nele

    ?????? Ich bin eigentlich immer davon ausgegangen, dass ein Modul in einem eigenen Scope abläuft. Dann habe ich noch folgendes ausprobiert:

    names = ["Annika", "linea", "nele"];
var namers = [];
var i = 0;
names.forEach(function(name){
    namers[i] = require('test');
    namers[i].updateName(name);
    i++;
});

    Eigentlich würde man annehmen, dass hier 3x eine neue "Instanz" von test angelegt wird, doch weit gefehlt: auch hier ist das Resultat:

    nele
nele
nele

    Und so funktioniert es:

    exports.updateName = function(namein) {
    var name = namein;
    setTimeout(function(){console.log("my name is: " + name)}, 1000);
}

    Das funktioniert jetzt natürlich wunderbar, da es sich lediglich um eine Funktion handelt, aber ich habe noch ein paar andere, welche auf diese name Variable zugreifen müssen. Ja ich könnte ein richtiges Object draus machen und dann this verwenden, doch im asynchronen Context funktioniert das dann leider nicht ganz fehlerfrei, da sich jeweils der Scope von this ändert.

    Update 15.08.2013: Und jetzt auch noch die (offizielle Erklärung)[http://nodejs.org/api/modules.html#modules_caching] von der Node.js Docs Seite:

    Modules are cached after the first time they are loaded. This means (among other things) that every call to require('foo') will get exactly the same object returned, if it would resolve to the same file.

    Multiple calls to require('foo') may not cause the module code to be executed multiple times. This is an important feature. With it, "partially done" objects can be returned, thus allowing transitive dependencies to be loaded even when they would cause cycles.

    If you want to have a module execute code multiple times, then export a function, and call that function.

  • Stolzer 100km von Biel Finisher

    Heute habe ich zum ersten Mal mein heiliges blaues 100km Biel Finisher T-Shirt an die frische Luft gebracht. Ein bisschen stolz war ich schon, muss ich zugeben und habe die ganze Zeit gehofft, dass die Leute den Text auf dem T-Shirt lesen können. Nur der reine Gedanken, dass ich die 100km geschafft habe, hat mir Flügel verliehen. Förmlich geflogen… lag wahrscheinlich auch daran, dass ich nur 9km gerannt bin und nicht 50km.

    Finisher 100km Biel

    Ich muss zugeben, dass ich schon ein bisschen froh bin, diese Mörderstrecke endlich hinter mir zu haben. Trainingsstrecken habe ich wieder auf eine normale Länge redimensioniert und so muss ich nach einer 9km Runde kein schlechtes Gewissen mehr haben und kann ruhig auch ein bisschen mehr Tempo machen und muss nich durch die Gegend schleichen.

    Der nächste Ernstkampf wird sicher nicht über 100km sein. Ein Marathon tuts auch. Scheint schon fast kläglich gegen 100km zu sein. Aber keine Sorge, die 100km habe ich noch nicht abgeschrieben. Das beste Alter für die Ultraläufe kommt ja noch.

    Kapitel 100km somit erfolgreich geschlossen.

  • Prism, gute Gelegenheit für ein Startup

    Täglich kommt wieder etwas Neues zum Abhörskandal. Auch Otto Normalverbraucher erfährt, dass sich Mails verschlüsseln lassen, dass es VPN gibt und dass man auch die Festplatte verschlüsseln könnte. Problem ist lediglich, dass das alles noch viel zu umständlich ist, und ich gebe offen zu, dass meine Mails bei Google liegen und ich meine E-mails auch nicht mit PGP (oder etwas ähnliches) verschlüssele. Ich bin einfach zu faul. Wahrscheinlich würde bereits eine halbe Stunde meiner Zeit eine Lösung zu Tage fördern (und hier gibts auch eine Anleitung dazu).

    Eigentlich wäre das eine super Gelegenheit ein Security Startup zu gründen. Alle Leute hören von Sicherheit, wissen jedoch nicht, was zu tun ist. Beste Gelegenheit, einen sicheren E-mail Dienst zu gründen:

    Deine E-mails sind 100% sicher hier. Verschüsselung und garantiert keine Hintertür.

    Features müssten sein:

    • One Click importer von Outlook.com, gmail und Apple Mail
    • Out of the box Verschlüsselung
    • Server in einem Rechtsstaat

    Kim Dotcom zumindest scheint die Gelegenheit zu nutzen… doch ob der mehr Vertrauen erweckt? Ich weiss nicht, ob ich dort meine E-mails speichern wollte mit dem Risiko, dass der Dienst in den kommenden paar Jahren abgeschalten wird, oder vielleicht doch lieber auf einen potentiell verwanzten, wenn auch zukunftssicheren Dienst setze.

    Oder wie wäre ein Dienst à la Dropbox, aber z.B. basierent auf der Bit Torrent Technologie BitTorrent Sync, auch hier, genau so einfach zu verwenden, aber z.B. Server frei wählbar in einem EU Land. Klaro kann man sich alles selber installieren, aber ist halt einfach meistens zu umständlich für Otto Normalverbraucher.

    Ein Brainstorming würde wahrscheinlich noch zig Ideen zu Tage fördern… aber irgendwie interessiert mich die Thematik nicht, um mehr Energie rein zu stecken. Kennt ihr schon Projekte, welche aktiv mit Prism werben?

  • Und das mag ich an Node.js

    Vor ungefähr 3 Monaten habe ich angefangen mich mit Node.js zu beschäftigen. Ganz natürlich tauche ich daher auch tiefer in die ganze Javascript Welt ein, den Node.js ist Javascript und entferne mich langsam aber sicher von der PHP Welt. Bin ich deswegen traurig?

    Noch habe ich ein grosses Stück Arbeit vor mir. Noch wird es unzählige kleine Hello World Anwendungen geben. Noch werde ich unzählige Male auf stackoverflow nach Antworten suchen. Noch gebe ich aber nicht auf. Noch lernen ich Node.js

    Faszination Node.js

    Zuerst fasziniert einfach mal die Performance von Node.js. Die Benchmarks mögen zum Teil wenig aussagekräftig sein und schlussendlich kommt es immer auf die Applikation an, aber egal, ich bin ein normaler Mensch und diese Zahlen haben ihre Spuren hinterlassen: Zumindest haben sie mein Interesse geweckt. Wer hätte vor 15 Jahren gedacht, dass Javascript eine ernstzunehmende Programmiersprache ist/wird.

    Ich erinnere mich noch an Zeiten, da war es eine ernsthafte Möglichkeit, dass Javascript deaktiviert ist. Als Entwickler musste man sich Gedanken machen, dass die Seite auch ohne Javascript funktioniert. Javascript war eine Sprache für Hacker, welche Unfug damit trieben und Kiddies, aber sicher nicht für ernstzunehmende Software Entwickler, ganz zu schweigen, um damit irgendwelche grossen Applikationen zu bauen. Und heute? Javascript rules the world!

    Der Start mit Node.js könnte einfacher nicht sein

    Ich bin also erst einmal ganz heiss darauf dieses Node.js näher anzuschauen und unter Linux ist Node.js auch schnell installiert. Es dauert ca. 10 Minuten und ich habe meine erste Hallo Welt Node.js Applikation:

    sudo apt-get install nodejs

    Schon ist node Installiert, jetzt nur noch schnell das Hello World

    // hello_node.js
var http = require('http');
http.createServer(function (req, res) {
  res.writeHead(200, {'Content-Type': 'text/plain'});
  res.end('Hello World');
}).listen(8124, "127.0.0.1");
console.log('Server running at http://127.0.0.1:8124/');

    Und den Nodeserver starten und schon habe ich in meinem Browser Hello World.

    node hello_node.js

    Wuala. Wenn ich an mein erstes PHP Hello World zurückdenke, dann war das doch massiv mehr aufwand: Apache installieren, PHP installieren und dann noch alles konfigurieren (und ja, vor 10 Jahren, war das doch noch ein bisschen manuelle Arbeit).

    Aber warum gerade Node.js?

    Schnell lerne ich die Basics und freue mich darüber, dass man einfach Module machen kann, merke jedoch auch schnell, dass es über ein paar jQuery Selektoren hinausgeht. Um eine Applikation zu schreiben muss ich mir erst mal Gedanken machen, wie das ganz zu strukturieren ist und jetzt fängt das lesen an, und noch viel wichtiger.

    Ich merke jedoch auch, dass ich diese Konzepte, welche ich hier lerne fast 1 zu 1 auf die Browserwelt übertragen kann. Da gibts ja requirejs.org, welches bestens für Modularisierung geeignet ist. Es stellt sich heraus, dass viele Funktionen einer App besser im Client sitzen sollten, und hurra, das kann ich jetzt durch meine verbesserten javascript Kentnisse auch problemlos umsetzen.

    Wenn ich mich auf der Serverseite bewege, dann lerne ich automatisch auch etwas für die Clientseite und umgekehrt. Dies war bis anhin ein grösseres Problem: 1-2 Monate Serverseitig programmiert (Python oder PHP) und schon geht das meiste Javascript Wissen und die denkweise verloren. Umgekehrt, ein bisschen im Browser gescriptet und schon geht die Lust am Server verloren: Node.js ermöglicht beides und noch viel besser: Code kann (wenn auch nicht immer 1:1) wiederverwendet werden!

    Die Synergien, welche sich aus Backend und Front-end ergeben sind bestens für einen Hobby Entwickler wie mich geeignet.

    Ist alles easy in Node.js

    Nein, überhaupt nicht. Diese asynchrone Welt ist ziemlich verdreht. Viele der bekannten OOP/Java Denkweisen und Patterns funktionieren einfach nicht so richtig. Javascript ist eine niftige kleine Sprache, die es in sich hat. Für alles gibt es zig verschiedene Möglichkeiten und ich weiss nach wievor nicht, was die Ninja Art ist, um eine Klasse zu erstellen. Des weiteren muss ich mich daran gewöhnen, dass die Applikationen nicht bei jedem Klick neu geladen und vom Server gerendert wird, sondern dass viel Logik im Client läuft und dieser Client einen Zustand hat: Erfordert viel Umdenken für einen alten PHP Hasen.

    Gebe ich auf? Nein, sicher nicht. Node.js ist cool.