Um dies möglichst einfach zu erreichen, schlage ich ein Source- (z.B. project/src) und ein Zielverzeichnis (z.B. project/build) vor. In src kann man weitere Grobstrukturen wie main und tests festlegen. So fließen meine zuvor definierten Tasks build_project und build_tests zu einem einzigen build zusammen.

Unterschiede erkennen? Rsync!

Um möglichst effizient etablierte Technologien verwenden zu können, werden vor dem Kompilieren alle Quelldateien ins Buildverzeichnis kopiert. Dank dieser Vereinfachung lässt sich Rsync verwenden, welches nur wirklich geänderte Dateien synchronisiert und ihren Pfad ausgibt. Nach dem Sync muss die Liste der Änderungen nur noch nach Coffee-Dateien durchsucht und diese kompiliert werden. Der gesamte Vorgang sieht dann folgendermaßen aus:

build() {
    changes=( "$(rsync -av "$source_directory/" "$build_directory")" )
    for filepath in $changes; do
      if [[ $filepath == *.coffee ]]; then
        $compiler --compile "$build_directory/$filepath"
      fi
    done
}

Einziger Schönheitsfehler: Im Buildverzeichnis liegen auch die Coffeescript-Dateien neben ihren Javascript-Äquivalenten, obwohl sie nicht gebraucht werden. Diese dürfen im Buildprozess nicht entfernt werden, da ihre Löschung den Rsync-Ansatz ad absurdum führt. Während der Entwicklung stören sie auch nicht. Für das produktive Deployment empfiehlt sich jedoch eine zusätzliche Task, die das Buildverzeichnis zuvor bereinigt.

Implementierte Build-Tasks

Das Script ist mittlerweile vollständig genug, um die Node-Entwicklung zu begleiten. Folgende Tasks stehen zur Verfügung:

Node-Build-Script auf Github

start_server() {
    echo "Start server..."
    $application_launcher "$build_directory/run-server.js" &
    echo $! > .serverpid
}

stop_server() {
    if [ -f ".serverpid" ]; then
        local server_pid=$(head -n 1 .serverpid)
        rm .serverpid
        if [[ $server_pid > 0 ]]; then
            echo "Stop server..."
            kill $server_pid
            server_pid=0
        fi
    fi
}

Es erscheint hier etwas unschön, stop_server() im Falle einer nicht gegebenen PID einfach nichts machen zu lassen. Die Bedingung sollte an der Aufrufstelle stehen oder der Funktionsname auf das nur bedingte Stoppen hinweisen. Da ich aber kurze und einfache Funktionen für ein Kommandozeilentool suche, halte ich diese Variante für pragmatisch und akzeptabel.

Im Argument-auf-Funktionsmapping des Scripts werden noch zwei oft genutzte Zusammenfassungen ergänzt:

process_tasks() {
    while [[ ${#tasks[@]} > 0 ]]; do
        local task=${tasks[0]}
        unset tasks[0]
        tasks=("${tasks[@]}")
        case "$task" in
            # ...
            'server')
                stop_server
                build_project
                start_server
            'restart-server')
                stop_server
                start_server
                ;;
            'start-server')
                start_server
                ;;
            'stop-server')
                stop_server
                ;;
            # ...
        esac
    done
}

Node-Build-Script auf Github

Boilerplate: Task-Abarbeitung

Auszuführende Aufgaben werden aus den Argumenten in ein Array tasks übernommen. Jede atomare Task Aufgabe hat eine Funktion (im Beispiel mytask()), welche die entsprechenden Operationen ausführt.

Die Abarbeitung selbst ist in process_tasks() definiert, was auch den Startpunkt des Scripts darstellt. Hier wird über das Aufgabenarray iteriert und anhand des Names die passende Funktion ausgeführt.

tasks=("${@:1}")

mytask() {
    # ...
}

# ...

process_tasks() {
    while [[ ${#tasks[@]} > 0 ]]; do
        local task=${tasks[0]}
        unset tasks[0]
        tasks=("${tasks[@]}")
        case "$task" in
            'mytask')
                mytask
                ;;
            # ...
        esac
    done
}

process_tasks

Testausführung mit Desktop-Benachrichtigungen

Die Funktion notify nimmt eine Nachricht und einen Typ (Erfolg oder Fehler) und stellt sie auf dem Desktop dar. Entsprechend des Typs wird ein Icon gewählt. Dieser Teil ist leider plattformabhängig. Für Linux habe ich notify-send gewählt.

Vom Unittest-Script wird hier in der Funktion run_tests erwartet, dass bei fehlgeschlagenen Tests auch ein Fehlercode, also ungleich 0, zurückgegeben wird. Ist dies nicht der Fall, muss hier die Ausgabe überwacht werden.

notify() {

    local message=$1      # the message to be sent
    local message_type=$2 # "error" || "success" || undefined

    if hash "notify-send" 2> /dev/null; then
        local icon="face-plain"
        if [[ "$message_type" == "error" ]]; then
            icon="error"
        elif [[ "$message_type" == "success" ]]; then
            icon="face-smile-big"
        fi
        notify-send -u low -t 500 -i "$icon" "$message"
    fi
}

run_tests() {
    $application_launcher $build_directory/test/precompiler.spec.js
    if [[ $? > 0 ]]; then
        notify "One or more tests failed!" "error"
    else
        notify "All tests passed." "success"
    fi
}

Watch: Dateisystem überwachen

Anwendung

Die Watchtask führt alle ihr nachfolgenden Tasks immer wieder aus, wenn sich im überwachten Verzeichnis etwas ändert.

./build.sh t1 t2 watch t3 t4

Die Aufgaben t1 und t2 werden direkt ausgeführt, ab watch wird gewartet. Mit jeder Änderung werden t3 und t4 ausgeführt. Ein sinnvolles Beispiel wäre somit:

./build.sh test watch test

Die Task test beinhaltet auch den Build. Der Aufruf führt die Tests zu Beginn und nach jeder Änderung aus.

Umsetzung

Das Dateisystem wird von inotifywait auf Änderungen überwacht. Es blockiert die Abarbeitung, bis eine Änderung vorgenommen wird. Hiernach werden die restlichen Tasks aus der Liste ausgeführt. Damit das Script dann nicht terminiert, wird die Taskliste um eine weitere Watch-Task und sich selbst ergänzt. So entsteht eine Endlosschleife.

watch() {
    tasks=("${tasks[@]}" "watch" "${tasks[@]}")
    inotifywait -rqe close_write,moved_to,create ./lib ./test
}

Code auf Github

Das Script kann als Vorlage für eigene Build-Scripts verwendet werden. Es steht unter der üblichen Für-alle-außer-Microsoft-und-Apple-Lizenz und ist auf Github zu finden:

Node-Build-Script auf Github

Ich betrachte für mich derzeit relevante Punkte, wie etwa:

• Einrückung
• if-Statements
• Stringausdrücke
• Variablendeklaration
• Semikolons

Mein Fazit: Den einen Node-Coding-Style gibt es nicht. Selbst die beiden Kernmodule weisen elementare Unterschiede auf. Den eigenen Stil muss man sich nach wie vor selbst zusammensuchen.

Eine Alternative: In Coffeescript ist der Code-Style Teil der Syntax, was konsistenten Code begünstigt.

Gemeinsamkeiten

Code-Einrückung

Zwei Leerzeichen:

Node FS

function read() {
  if (size === 0) {
    buffer = new Buffer(8192);
    fs.read(fd, buffer, 0, 8192, -1, afterRead);
  } else {
    fs.read(fd, buffer, pos, size - pos, -1, afterRead);
  }
}

Einzeilige If-Bedingungen

Meist einzeilig, aber nicht konsequent. In Verbindung mit else immer geklammert und mehrzeilig.

Node FS

if (er) return callback(er);
if (bytesRead === 0) {
  return close();
}

Argumentlisten

Keine Leerzeichen zwischen Klammer und Argument, Argumente durch Komma und Leerzeichen getrennt:

NPM

cb(null, made)

Strict-Mode

Keines der beiden Module verwendet den Strict-Mode von ECMA-Script 5.

Unterschiede

Variablen deklarieren

Node FS

var binding = process.binding('fs');
var constants = process.binding('constants');
var fs = exports;

NPM

var EventEmitter = require("events").EventEmitter
  , npm = module.exports = new EventEmitter
  , config = require("./config.js")

Verwendung von Semikolons

Node FS

Übliche, konsequente Verwendung des Semikolons am Ende eines Ausdrucks:

var kMinPoolSpace = 128;

return function(err) {
  if (err) {
    throw err;
  }
};

fs.Stats.prototype._checkModeProperty = function(property) {
  return ((this.mode & constants.S_IFMT) === property);
};

NPM

Soweit möglich konsequenter Verzicht auf Semikolons:

var cmd = require(__dirname+"/"+a+".js")

function defaultCb (er, data) {
  if (er) console.error(er.stack || er.message)
  else console.log(data)
}

npm.deref = function (c) {
  // ...
  var a = abbrevs[c]
  if (aliases[a]) a = aliases[a]
  return a
}

Stringausdrücke

Einfache Anführungszeichen, Leerzeichen zwischen String und Operator:

Node FS

'Unknown file open flag: ' + flag

NPM

Doppelte Anführungszeichen, keine Leerzeichen zwischen String und Operator:

"npm requires node version: "+j.engines.node

Vergleichsoperatoren: == gegen ===

Node FS

Kein konsequent beachteter Stil:

typeof data == 'string'
typeof arg1 === 'string'

NPM

typeof cli === "function"

Objektliterale

Node FS

Meist einzeilig:

options = { encoding: 'utf8', mode: 438 /*=0666*/, flag: 'a' };

NPM

Wie Variablendeklaration mehrzeilig mit vorgestelltem Komma:

npm.modes = { exec: 0777 & (~umask)
 , file: 0666 & (~umask)
 , umask: umask }

// in B/app.js
process.chdir(__dirname);

// oder in B/sub/file.js
process.chdir(__dirname + '/../');

Ist kein Aprilscherz. Dafür wählt Youtube endlich seinen Gewinner:

[youtube clip_id=“H542nLTTbu0″]

Die Node-Applikation

Die einzurichtende Node-App ist nichts besonderes: Ein Express-Webserver aus Javascript und Coffescript. Getestet wird das Ganze mit Jasmine-Node, der Node-Variante des beliebten Testframeworks.

Der Javascript-Task-Runner Grunt

Die Grundlage für die Übersetzung und Echtzeitfunktionen bietet das Javascript-Build-Tool Grunt. Wie man ein Projekt damit anlegt ist auf der Seite Getting Started recht gut beschrieben (genau genommen finde ich die Beschreibung gar nicht so doll, habe aber keine Lust es besser zu machen).

Von Haus aus kann Grunt in etwa gar nichts, alles ist streng modular und muss manuell hinzugefügt werden. Ich brauche die folgenden Plugins:

grunt-contrib-copy

Mit Copy verschiebe ich reine Javascript-Dateien und andere Resourcen vom Source- ins Buildverzeichnis.

grunt-contrib-coffee

Mit der Coffee-Task schiebe ich Coffee-Dateien vom Source- ins Buildverzeichnis. Statt sie nur zu kopieren, werden sie dabei auch direkt in Javascript umgewandelt.

grunt-contrib-jasmine-node

Dieser Task dient dazu, nach dem Build auch Jasmine-Node-Unittests ausführen zu können (nicht mit grunt-contrib-jasmine für Frontend-Tests zu verwechseln). Tatsächlich nutze ich dieses Plugin nicht direkt, da ich eine Modifikation benötige (mehr dazu gleich).

grunt-contrib-watch

Dieses Modul überwacht ein angegebenes Verzeichnis auf Änderungen und startet jeweils eine spezifizierte Task. In meinem Fall ist das der Build (Copy und Coffee) sowie die Unittests.

Im Wesentlichen war es das auch schon: Die App wird bei jedem Speichern gebaut und automatisch getestet. Nur doof, dass man für die Ergebnisse ins Terminal gucken muss.

Testergebnisse als Desktop-Benachrichtigung

Hier konnte ich keinen wirklich eleganten Ansatz finden, der folgende Weg macht aber was wir wollen. Statt grant-contib-jasmine-node zu verwenden, kopieren wir uns die Task-Registrierung direkt in unser Gruntfile. Hier modifizieren wir die folgende Zeile:

var write = function(data) { process.stdout.write(data.toString()); }

Bevor die Write-Funktion die Nachricht in den Stdout schreibt, müssen wir analysieren, ob es sich um unsere Unittest-Ergebnisse handelt. Sieht die Nachricht etwa wie „x tests, y assertions, z failures“ aus, können wir Test- und Fehlerzahl direkt herausholen.

Nun, da wir unsere Ergebnisse extrahiert haben, müssen wir sie auf dem Desktop ausgeben. Ich nutze hierfür Notify-Send, welches Ubuntus Notify-Send-Benachrichtigungen bedient. Ggf. muss das Paket erst installiert werden. Für proprietäre Systeme gibt es andere Lösungen, die vergleichbar funktionieren.

„Für jeden Job das passende Werkzeug“ führt gern zu folgenden Strukturen auf Server und Entwicklungsumgebung:

http://localhost:8080/tomcat-project
http://localhost:8081/node-project
http://localhost:8082/php-project

Ein Albtraum für jeden Ajax-Entwickler. Mit Nginx lassen sich verschiedene Hosts und Ports zusammenfassen.

Nginx unter Ubuntu installieren und konfigurieren

sudo apt-get install nginx

Ähm… Fertig. Linux eben. Nun die Konfigurationdatei

/etc/nginx/sites-available/default

etwa folgendermaßen anpassen:

server {
    listen   80;
    server_name localhost;

    location /tomcat-project/ {
        proxy_pass http://127.0.0.1:8080/tomcat-project/;
    }

    location /node-project/ {
        proxy_pass http://127.0.0.1:8081/node-project/;
    }

    location /php-project/ {
        proxy_pass http://127.0.0.1:8082/php-project/;
    }
}

Standardport des Apache ändern

Wird PHP mittels Apache ausgeliefert, muss der standardmäßig verwendete Port 80 geändert werden. Hierfür die 80 in den folgenden Dateien auf den Wunschport (im Beispiel oben etwa 8082) umstellen:

/etc/apache2/ports.conf
/etc/apache2/sites-available/default
/etc/apache2/sites-available/*

Abschließend Apache und Nginx neustarten:

sudo /etc/init.d/apache2 restart
sudo /etc/init.d/nginx restart

Selber Host, selber Port

Nun lassen sich verschiedene Webserver (technologisch oder gar physisch getrennt) über die selbe Adresse erreichen:

http://localhost/tomcat-project
http://localhost/node-project
http://localhost/php-project

Das Beispiel bezieht sich lediglich auf HTTP, kann aber analog für beispielsweise HTTPS (Port 443 statt 80) konfiguriert werden.

Um hier keinen falschen Eindruck aufkommen zu lassen: Nginx kann noch weitaus mehr. So ist ein Apache unter Umständen gar nicht notwendig und PHP kann als CGI direkt ausgeführt werden. Die offizielle Dokumentation sollte einen etwas umfangreicheren Überblick liefern.

wget http://nodejs.org/dist/v0.8.14/node-v0.8.14.tar.gz
tar -xf node-v0.8.14.tar.gz
cd node-v0.8.14
./configure
make
sudo make install

Nun ein Beispielskript erstellen…

echo -e "var http = require('http');\nhttp.createServer(function (req, res) {\n  res.writeHead(200, {'Content-Type': 'text/plain'});\n  res.end('Hello World\\\n');\n}).listen(1337, '127.0.0.1');\nconsole.log('Server running at http://127.0.0.1:1337/');" > example.js

… und starten:

node example.js

http://127.0.0.1:1337/ im Browser öffnen.

Wer fremden Quellen auf dem Server traut, kann auch ein PPA wie das von Chris Lea nutzen. Zudem macht das Updates einfacher. Da Node aber noch recht frisch und somit potentiell API-instabil ist, können solche Updates aber auch zu Problemen führen. Hier gilt es abzuwägen.

Das Beispielskript stammt von nodejs.org.