Am 8. Oktober 2014 haben wir daher mit acht Studienkollegen einen kurzen Usability-Test durchgeführt, um unseren iOS Prototyp zu testen. Dieser umfasste zu diesem Zeitpunkt neun Screens, die einen Event-Erstellungsprozess abbilden.

Der Test hat viele Erkenntnisse zu Tage gebracht. Einerseits wurden einige Bugs gefunden. Beispielsweise ist die App an manchen Stellen abgestürzt. Das was uns aber besonders wichtig war, waren Usability-, UX- oder Verständnis-Probleme.

Probleme

Desiree Zottl Problem
Nach dem Login, kamen die User auf den Start-Screen, welcher zu diesem Zeitpunkt nicht sehr viel zeigt, bis auf eine Box mit dem User-Profil und einem Button. Vier von acht Probanden, haben sich hier sehr gewundert, dass sie Desiree Zottl sind.

Start-Screen leitet auf keine Aktion hin
Auf dem Start-Screen waren viele User ein wenig verloren. Ohne den Hinweis, dass sie bitte jetzt ein neues Event anlegen sollen, hätte kaum jemand den grünen Button gefunden.

Durch Tastatur wichtige Funktion abgeschnitten
Beim Lösen mancher Aufgaben hatten die Probanden Probleme wichtige Funktionen zu erwischen, da sie durch die Tastatur oder Suchergebnisse abgeschnitten oder nicht erreichbar waren.

Switch unklar
Beim Hinzufügen eines Termins zu einem Event kann mit einem Switch zwischen ganztägigen und zeitabhängigen Terminen gewechselt werden. Hier war für einige Probanden unklar, ob der Switch gerade aktiv ist oder nicht.

Buttons teilweise zu klein
Einige der Buttons sind zu klein und mussten von den Testperson oft mehrmals gedrückt werden, bevor die Funktion ausgeführt wurde. Dies hat natürlich Verwirrung gestiftet, weil die Testpersonen den Eindruck hatten, dass etwas nicht funktioniert hat.

Pflichtfelder hervorheben
In einigen Fällen war es für die Probanden unklar, welche Felder ausgefüllt werden müssen und welche nicht. Es ist auch nicht eindeutig, ab wann ein Event ausreichend ausgefüllt ist, um es speichern zu können.

Viele Schritte
Einige Probanden haben angemerkt, dass es eventuell mühsam ist so viele Schritten durchlaufen zu müssen, wenn man die App oft nützt.

Zum Ausfüllen Extra-Klick notwendig
Bei den meisten Screens muss zuerst ein Plus-Button gedrückt werden, bevor die Felder ausgefüllt werden können. Ein Proband hat angemerkt, dass das eigentlich nicht notwendig ist und Zeit verbraucht.

Verwirrende Navigation bei Zusammenfassung
Tippt man von der Zusammenfassung auf einen der Bereiche, springt man quasi wieder zurück und muss dann alle folgenden Schritte erneut durchlaufen. Das hat bei einigen Probanden für Verwirrung gesorgt.

Lösungen

Start-Screen
Da der Start-Screen beim ersten Aufruf sehr leer ist soll er in Zukunft von Anfang an mehr dazu einladen neue Events anzulegen. Auch wollen wir eventuell auf das Anlagen eines Profils für Gatherer verzichten.

Wo zu Was
Um die Anzahl der Schritte bis zum Beenden des Erstellungsprozesses zu reduzieren und Events zu vereinfachen wird der “Wo”-Screen wegfallen und als einfaches Textfeld in den “Was”-Screen wandern.

Unklarheiten aufräumen
Einige Dinge, waren nicht zu 100% klar bei den Usern, die wollen wir in nächster Zeit versuchen auszuräumen.

The post Gatherer: der erst Test appeared first on Mobile USTP MKL.

Die Themen der Konferenz waren sehr vielfältig. Das Spektrum reichte von Entwickler-Themen wie Angular JS und weiteren JavaScript Vorträgen über Responsive Web Design und SASS bis hin zu User Interface Design und Daten Visualisierung. Dadurch konnte sich jede/r die interessantesten Themen heraussuchen.

Einer der spannendsten Vorträge war der des Gründers des bekannten Smashing Magazine, Vitaly Friedman (Twitter: @smashingmag), über Responsive Web Design. Der Talk mit dem Titel “Real-Life Responsive Web Design” deckte sehr viele wichtige Aspekte ab, die heutzutage für die Erstellung von flexiblen Web-Projekten wichtig sind.

Auch sehr spannend war der Vortrag von Monica Dinculescu (Twitter: @notwaldorf). Sie arbeitet bei Google an der Entwicklung des eigenen Browsers Chrome und sprach über sechs Tricks, wie Google seine Chrome User glücklich macht. Damit gab sie einen spannenden Einblick hinter die Kulissen der Arbeit von Google.

Die Designer/innen und Entwickler/innen der Masterklasse Mobiles Internet konnten sehr viel aus den verschiedenen Vorträgen mitnehmen und werden auch bei der nächsten Konferenz in Österreich wieder dabei sein.

The post codefront.io appeared first on Mobile USTP MKL.

Queues

Nun, viele Entwickler implementieren diesen E-Mail verschick-Prozess direkt in den ersten Response. Was folgt? Der Response dauert länger. Das Script führt nicht nur die eigenen Operationen durch, rendert das Template, sondern muss zusätzlich eine SMTP Verbindung öffnen und ein E-Mail verschicken. Das kann mit unter zu sehr nervigen Reaktionen bei den Usern führen, vor allem wenn es um keine banale Registrierung sondern eine komplexere Firmen Web-Applikation handelt die beispielsweise E-Mails verschickt wenn man zu einem bestimmten Projekt Issue einen Kommentar abgibt.
Der Schlüssel hier sind Job Queues. Einfach gesagt lagert man spezielle Funktionalitäten absichtlich aus um Responses weiterhin schnell abwickeln zu lassen. Man “ent-blockt” sozusagen das System bzw. den Response und Redis hilft uns hier sehr gut weiter.

Redis

Redis selbst ist ein einfacher Key-Value Store und betitelt sich selbst oft als “data structure server” da in den einzelnen Value Feldern nicht nur gewöhnliche Zeichen gespeichert werden können, sondern auch komplexe hashes, listen oder sortierte sets. Die zwei größten Vorteile von Redis sind 1. die Schnelligkeit (auf Grund des einfachen Aufbaus) und 2. das Event Handling. Man kann beispielsweise auf einen gewissen Kanal horchen und wird informiert falls neue Daten reinkommen und kann dementsprechend reagieren.

Node.js

Node ist ein großer Haufen toller Sachen, aber grob Zusammengefasst ist Node ein Wrapper um die V8 von Google (JavaScript Interpreter) mit zusätzlichen Libraries (z.B. FileSystem, HTTP uvm.) und bringt somit JavaScript auf die Server-Seite. Es gibt bereits viele gute Redis Packages die uns die Verbindung zum Redis Server erleichtern, sucht man jedoch etwas genauer findet man sogar schon Libraries die uns genau unseren Job abnehmen. Eine dieser Libraries ist Kue.

Dig in!

Ich werde nicht darauf eingehen wie man ein Node Projekt startet oder Kue als Dependency integriert, denn das kann man sich auf den jeweiligen Repositories gut dokumentiert ansehen. Wie erstellt man nun asynchrone jobs?
Man bindet zuerst die notwendigen Libraries ein:

// email job module - job-email.js
var kue = require('kue')
  , jobs = kue.createQueue();

Danach erstellt man die Funktion die uns einen Job generiert:

/**
 * email => {
 *   to: "foo@email.com",
 *   from: "bar@email.com",
 *   subject: "Some Subject",
 *   message: "Hello World!"
 * }
 */
function newEmailJob (email) {
  var job = jobs.create('new email', email);
  job
    .on('complete', function () {
      console.log('Email', job.id, 'with subject', job.data.subject, 'is done!');
    })
    .on('failed', function () {
      console.log('Email', job.id, 'with subject', job.data.subject, 'has failed!');
    });
  job.save();
}

Zuerst wird die Funktions `jobs.create()` verwendet um einen Job zu generieren. Dabei werden Typ des Jobs und ein Objekt mit den Daten übergeben. Als nächstes werden über die `jobs.on()` Funktion 2 Events mit Callbacks gespeichert, damit die Library weiß was sie Ausführen soll falls der Job fehlerfrei abgearbeitet wurde oder ein Fehler eingetreten ist.

Als nächstes rufen wir die Funktion `jobs.process()` auf und übergeben das eigentliche Callback zum bearbeiten des Jobs bzw. verschicken des E-Mails.

jobs.process('new email', 20, function (job, done) {
 // email versenden ...
 // email objekt liegt in job.data ...
 // ...

 done && done();
});

Normalerweise wird von Kue nur ein Job auf einmal ausgeführt, das ist bei großen Jobs vielleicht auch sinnvoll, doch beim E-Mails verschicken können wir hier die maximale Anzahl an zu-bearbeitenden Jobs z.B. auf 20 setzen. Das heißt hier werden gleichzeitig 20 Queue Einträge vom Typ E-Mail aus Redis auf einmal rausgenommen und bearbeitet. Node.js ist hier ganz gut darin.

Zu guter letzt müssen wir unsere Funktion nur mehr aufrufen:

newEmailJob({ to: "...", from: "...", ... });

Unter der Haube wird dabei das E-Mail Objekt in Redis gespeichert, zeitgleich hört `jobs.process()` aber auch auf Änderungen in der E-Mail Collection und führt daraufhin für jeden neuen Eintrag die selbst-definierte Callback Funktion aus (nämlich das E-Mail versenden). Sobald dies geschehen ist wird der Eintrag auch wieder aus Redis rausgelöscht. Wer genaueres wissen möchte und seine Queue beispielsweise in einer anderen Sprache implementieren möchte kann sich hier wieder passende Libraries suchen oder sich direkt die PUB/SUB Methoden für Redis ansehen.

Summary

Queues können für allerlei Abarbeitungen verwendet werden um Requests im Web nicht zu blockieren. Redis ist genau hier ein sehr gutes Tool dafür. Läuft man beispielsweise auch noch auf PHP und hat ein blockierendes I/O System sind Queues umso wichtiger.

The post Job Queues mit Redis appeared first on Mobile USTP MKL.

Sails.js baut auf dem Express.js Web Framework auf und erweitert dieses um genau die Funktionalitäten wofür es für eine komplexe Backend Applikation zu schlank ist.

Waterline ORM

Mike McNeill hat nicht nur Sails entworfen, sondern auch Waterline.js, einen schlanken Datenbank agnostischen O/R Mapper der von Sails direkt verwendet wird. Waterline ist deshalb so praktisch weil es funktioniert, egal welche Datenbank man verwendet. Waterline’s Data Access Layer funktioniert über sogenannte Adapter, die man pro Datenbanksystem erstellen und konfigurieren kann. Genau genommen gibt es sogar einen vorintegrierten Filesystem Adapter der Models auf dem Filesystem abspeichert. Über GitHub findet man bereits Adapter für die verschiedensten relationalen und objektorientierten Datenbanksysteme wie MySQL oder MongoDB und schlimmstenfalls schreibt man den Adapter einfach selbst.

// config/adapters.js
module.exports.adapters = {
  'default': 'mysql',

  disk: {
    module: 'sails-disk'
  },

  mysql: {
    module: 'sails-mysql',
    host: 'YOUR_MYSQL_SERVER_HOSTNAME_OR_IP_ADDRESS',
    user: 'YOUR_MYSQL_USER',
    password: 'YOUR_MYSQL_PASSWORD',
    database: 'YOUR_MYSQL_DB'
  }
}

Models and Lifecycle Callbacks

Models funktionieren in Sails.js genauso wie in jedem anderem MVC Framework. Es wird ein Entity erstellt, welches die Attribute beschreibt. Einziger Unterschied: Das Model ist zwar ein Objekt, die Attributswerte sind jedoch keine nativen Datentypen aus der Scriptsprache sondern Strings und werden dann pro Adapter anders für das Datenbanksystem gemappt. Dadurch ist auch keine zusätzliche Annotation für das ORM notwendig.

// models/person.js
module.exports = {
  attributes: {
    firstName: 'STRING',
    lastName: 'STRING',
    age: {
      type: 'INTEGER',
      max: 150,
      required: true
    },
    emailAddress: {
      type: 'email', // Email type will get validated by the ORM
      required: true
    }
  },
  beforeCreate: function () {
     // ...
  }
};

Models in Sails.js werden außerdem von Waterline validiert, dazu gibt es eine Liste an Typen die man sich in der Sails Dokumentation ansehen kann. Weiters ist es möglich Lifecycle Callbacks zu implementieren, das sind Funktionen die an bestimmten Zeitpunkten automatisch aufgerufen werden und auf die man wie bei Delegates reagieren kann. Typische Callback Funktionen wären:

- beforeCreate / *fn(values, cb)*
- afterCreate / *fn(newlyInsertedRecord, cb)*
- beforeUpdate / *fn(valuesToUpdate, cb)*
- afterUpdate / *fn(updatedRecord, cb)*
- beforeDestroy / *fn(criteria, cb)*
- afterDestroy / *fn(cb)*

RESTfull JSON API in 5 seconds

Sails erstellt zu jedem Model eine bereits fertig funktionierende json-basierte REST Api. Das bedeutet dass man sich überhaupt nicht mehr um eine REST Library kümmern muss, oder mühsam alle CRUD Funktionen mit den passenden HTTP Methoden implementieren muss. Die Magie dahinter steckt in den sogenannten Controller Blueprints – sprich Blaupausen – die man in der controller.js Konfiguration sehen kann.

Eine nette Einführung in die REST Features von Sails.js und eine Demo der Blueprints findet man hier:
https://www.youtube.com/watch?v=GK-tFvpIR7c

Blueprints for Actions

Schaltet man die `action` blueprints ein so erstellt Sails automatisch alle Routen für die entsprechenden Controller actions. Sprich die `sayHi` action vom Controller `Person` würde über `http://localhost:1337/person/sayHi` erreichbar sein. Das ist soweit noch nichts neues, das bieten sogar die meisten Frameworks bereits out-of-the-box an. Zusätzlich erstellen die `action` blueprints aber auch Routen für alle 4 HTTP Methoden (GET, POST, PUT, DELETE) und binden sie an jede Action Methode. Dadurch kann man in der Action bequem auf den Methodentyp abfragen und zusätzlich differenzieren. Zusätzlich bekommt jede Action einen optionalen `id` Parameter.

GET     /email/send/:id?
POST    /email/send/:id?
PUT     /email/send/:id?
DELETE  /email/send/:id?

Blueprints for REST

Etwas interessanteres sind beispielsweise die `rest` blueprints. Diese erstellen wie bereits oben angedeutet unter der Haube alle 4 CRUD Methoden mit den dazugehörigen Routen. Das ist in vielen Fällen sehr praktisch und erleichtert einem viel mühsame Arbeit, zumal diese Actions und Routen für jedes Model automatisch generiert werden. Das bedeutet also, dass Sails hier bereits folgende Bindings unternimmt:

GET      /person           -> PersonController.findAll
GET      /person/:id?      -> PersonController.find
POST     /person           -> PersonController.create
PUT      /person/:id       -> PersonController.update
DELETE   /person/:id       -> PersonController.destroy

Blueprints for Shortcuts

Die dritte Möglichkeit ist mehr oder weniger eine weitere Beschleunigung und ermöglicht es, falls aktiviert, dass Sails für alle CRUD Methoden GET Routen anlegt und an die Actions bindet. Das bedeutet also, dass man alleinig über die Browserleiste alle 4 CRUD Methoden aufrufen kann. Das ist zwar sehr praktisch fürs Testing, da man keine Forms, Javascript oder sonstige REST Client Plugins braucht um die Methoden aufzurufen, aber Sails unterstreicht hier stark dass es aus Sicherheitsgründen für den Production Bereich deaktiviert werden sollte. Shortcuts würden folgendes ausschließlich über GET möglich machen:

GET      /person/create?name=&age=      -> PersonController.create
GET      /person/:id/update?name=&age=  -> PersonController.update
GET      /person/delete/:id             -> PersonController.destroy

Socket.io, Boom!

Sails.js verwendet für alle asynchronen Requests Socket.io und somit eine flexible Library mit vielen Fallbacks. Socket.io wird dabei von Sails.js gewrappt und ist am Client sowie am Server bereits fertig implementiert. Keine Handshakes, keine manuellen Verbindungen vom Client aus, alles out-of-the-box. Es ist also nicht mehr notwendig AJAX calls z.B. per jQuery zu machen, man nimmt einfach die globale `socket` Variable am Client und ruft einfach die Route am Server auf, die die Ressource liefern soll.

// json von allen personen abrufen
socket.get('/person', function (err, data) {
    // ...
});

Assets love Grunt

Sails.js nutzt Grunt um einige Tätigkeiten zu automatisieren. Beispielsweise werden über Grunt alle neuen bzw. veränderten Assets vollautomatisch vom internen Assets Ordner in den öffentlich zugänglichen kopiert. Dabei kann man Grunt weiterkonfigurieren und CSS Präprozessoren einbetten, welche sobald sich beispielsweise eine SASS Datei verändert hat, diese direkt parst und in den public Assets Ordner verschiebt. Eine weitere Funktionalität ist die automatische Minifizierung sobald man den Modus auf Production wechselt. Sails.js nimmt dabei alle Assets her, minifiziert sie und linkt sie automatisch zurück ins Layout.

Multiple Template Engines

Ein sehr praktisches Feature ist die einfache Änderung von Templating Engines in Sails.js. Man kann entweder bei der Erstellung des Projekts über den `sails new projectname –template=engine` Befehl oder nachträglich über die Konfiguration die Template Engine definieren. Sails unterstützt dabei eine riesige Anzahl an Engines wie z.B.: underscore, hogan, haml, dust, swig, ejs, toffee, walrus, & whiskers, wobei ejs die standards templating engine ist. Es ist allerdings wichtig zu wissen, dass nach einer Änderung eventuell das Grunt File upzudaten ist, da sonst die Assets nicht richtig kopiert werden und der Server bei jeder Client Datei Änderung neugestartet werden müsste.

Integrated Async.js

Um der Callback Hell zu entkommen, welche bei stark event gesteuerten Segmenten in einer Applikation enstehen können, implementiert Sails.js bereits Async.js out-of-the-box. Async.js verfügt über ein paar sehr praktische Methoden um Callbacks parallel oder seriell ausführen zu können. Im Sonderfall kann man sogar Async.js selbst entscheiden lassen, welches Callback zuerst aufgerufen wurde. Ein einfaches Beispiel für eine serielle, statt üblicherweise verschachtelte Abwicklung:

var gameId = 7;

// normal
Game.find(gameId).done(function (err, game) {
   Reviews.findAllByGameId(game.id).done(function (err, reviews) {
      // [object] game
      // [object] reviews
   });
});

// with async.js
async.seriel({
  game: Game.find(gameId).done, // callback 1
  reviews: Review.findAllByGameId(gameId).done // callback 2
}, function (err, results) {
  // [object] results.game
  // [object] results.reviews
});

Fazit

Sails.js ist meiner Meinung `das` Beispiel schlechthin wie viel Potential in Node.js steckt. Zudem ist Sails.js gerade noch in Kinderschuhen und soll mit Version 0.10 nun auch Datenbank Relationen mit HAS_ONE, BELONGS_TO etc. mappen können. Die integrierten Blueprints für eine API sind unvorstellbar mächtig und die Integration von Socket.io macht das ganze zum Kinderspiel. Ich lege jedem Web Developer Sails.js ans Herz, der sich nach jahrelangen Krämpfen von PHP trennen möchte und ein Projekt sucht um sich mit Node anzufreunden. Das Entwickeln mit JavaScript auf sowohl Client als auch Serverseite mit den teilweise gleichen globalen Objekten ist sehr bequem. Wer PHP für seine Applikation weiterverwenden will und Sails.js als einfache API für seine Projekte nutzen möchte ist auf jeden Fall auch im richtigen Boot, denn einfacher geht es kaum.

Stay tuned für Teil 2 – die Kombination von Client und Serverseite mit Backbone und Sails von Desireé Zottl.

The post Teil 1: Sails.js Einführung in das Backend MVC Framework appeared first on Mobile USTP MKL.

Unwind Segues ermöglichen es zu vorherigen ViewControllern zurückzuwechseln. Ein entscheidender Vorteil ist zudem, dass nicht nur auf den direkten ViewController davor sondern irgendeinen vorherigen zurück gewechselt werden kann. Xcode ermittelt dabei die Animationsart die für das Hinkommen zum Controller verwendet wurde und nimmt davon die umgekehrte Animation. Ich habe für diesen Artikel bereits 4 verschiedene ViewController vorbereitet und sie mit einer modal-Segue miteinander verbunden.

Einzige Vorraussetzung ist, dass der Ziel-ViewController zu dem man zurück möchte eine spezielle Action definiert welche eine Unwind Segue als Parameter bekommt. Das sieht dann beispielsweise so aus:

@implementation ViewController

- (void)viewDidLoad {
  [super viewDidLoad]
  // Do any additional setup after loading the view, typically from a nib.
}

- (void)didReceiveMemoryWarning {
  [super didReceiveMemoryWarning];
  // Dispose of any resources that can be recreated.
}

- (IBAction)unwindToWhiteViewController:(UIStoryboardSegue *)segue {}

@end

Das tolle an dieser Funktion ist, dass sie ähnlich funktioniert wie `prepareForSegue`. Das bedeutet, dass in der Funktion alles ausgeführt wird bevor die eigentliche Segue Animation gestartet wird. Man könnte hier also sehr wohl über die Segue den Source ViewController ermitteln und abfragen ob es überhaupt der erwünschte ist (falls mehrere View Controller zurück zum ersten führen). Weiters hat man hier eine Schnittstelle und kann über den Source ViewController die Properties ermitteln falls Daten übergeben werden sollen.

- (IBAction)unwindToWhiteViewController:(UIStoryboardSegue *)segue {

  UIViewController* sourceViewController = unwindSegue.sourceViewController;

  if ([sourceViewController isKindOfClass:[OrangeViewController class]])
  {
    NSLog(@"I'm coming from Orange!");
  }
  else if ([sourceViewController isKindOfClass:[GreenViewController class]])
  {
    NSLog(@"I'm coming from Green!");
  }

}

Hat man die Funktion bereits implementiert, muss man nur noch den Button auf das Exit Symbol vom Quell ViewController ziehen. In diesem Fall möchten wir vom Grünen ViewController zurück zum Weißen.

Danach sollte ein kleines Popup erscheinen und die alle definierten Unwind Actions anzeigen. Wenn man alles richtig gemacht hat sollte hier also die Unwind Segue aufscheinen.

Das wars auch schon! Zusätzlich kann man die Segue auch im Document Outline markieren und ihr im Attributes Inspector einen Identifier geben. Das hat den Vorteil, dass man die Segue danach auch progammatisch triggern kann wenn man möchte.

The post Unwind Segues To The Rescue appeared first on Mobile USTP MKL.

Installieren von Express

Installiert man Express.js als globales Modul über `npm install -g express` kann man mit `express express-skeleton` ein Skeleton – sprich eine automatische Ordnerstruktur für die Applikation erstellen. Diese sieht wie folgt aus:

   - app.js
   - package.json
   + public
        + images
        + javascripts
        + stylesheets
             - style.css
   + routes
        - index.js
        - user.js
   + views
        - index.jade
        - layout.jade

Man erkennt schnell, dass bis zur Implementierung des MVC Musters noch ein wenig Arbeit erforderlich ist. Express vermischt hier das Routing direkt mit dem Controller Pattern, in dem es die Routes direkt in `app.js` anführt und dort auf die reinen Controller-Actions verweist.

// app.js
app.get('/', routes.index);

// routes/index.js
exports.index = function(req, res) {
   res.render('index', { title: 'Express' });
};

Applikationskonfiguration

Um die Applikation etwas flexibler zu machen, werden wir vorerst in Rootebene des Projekts einen neuen `config` Ordner erstellen und eine Datei namens `app.js` anlegen. Diese Datei wird unsere allgemeine Applikationskonfiguration beinhalten. Klassisch sind Sprache und ein CSRF Token falls man das Session Modul von Express verwendet. Das Modul besteht aus einem einfachen Objekt:

// config/app.js
module.exports = {
   language: 'en',
   session: {
      secret: 'mySessionSecret123'
   }
   // other configuration ...
}

Importiert wird die Konfiguration einfach per:

// app.js
var config = require('./config/app.js');

Controller und Routing

Die erste sinnvolle Erweiterung wäre es die Routes im `routes` Verzeichnis in Controller umzuwandeln, welche einfach dem JavaScript Konstruktor und Modul Pattern folgen. Man könnte den Controller auch als Objekt implementieren, der entscheidende Vorteil einer Funktion ist jedoch die Kapselung und die Möglichkeit andere Objekte über die Funktionsparameter zu injizieren. Im ersten Schritt benennen wir also das `routes` Verzeichnis in `controllers` um und bearbeiten die `index.js` wie folgt:

// controllers/index.js
module.exports = function () {
   // possible attributes or requires ...

   return {
      rootAction: function (req, res) {
         res.render('index', { title: 'Express Advanced' });
      }
   };
}

Der erste signifikante Vorteil hier ist, dass Attribute definiert werden können, die nur dem Controller zugeordnet sind. Hier können Konfigurationen oder beispielsweise ORM EntitiyManager geladen und initialisiert werden. Dem Controller können außerdem, wie bereits beschrieben, per Dependency Injection Objekte direkt in die (jetzt gerade leeren) Funktionsparameter injiziert werden.

Nun wäre es an der Reihe die Routendefinitionen aus der `app.js` in eine Routen-Konfigurationsdatei outzusourcen. Wir erstellen also in unserem `config` Ordner eine `routes.js` Datei. Diese Datei beinhaltet nun alle unsere Routes, welche auf unsere Controller verweisen:

// config/routes.js
module.exports = function () {
   // get required controllers
   var controller = {
      'index': require('../controllers/index.js')()
   };

   // define routes
   app.get('/', controller.index.rootAction);
   app.get('/blog', controller.index.blogAction);
   app.get('/login', controller.index.loginAction);
   app.post('/login', controller.index.checkLoginAction)
};

In der `app.js` importiert man die Konfigurationsdatei mit den Routes einfach mit:

// app.js
require('./config/routes.js')();

Models und Entities

Applikationslogik landet überlicherweise im Business- bzw. Domänenlayer und nicht im Controller selbst. Aus diesem Grund erstellen wir einen `models` Ordner in unserer Rootebene des Projekts. Darin erstellen wir direkt ein Unterverzeichnis namens `entities`, welches unsere Entitäten beinhalten wird. Solche Entitäten bilden unsere Domänenobjekte bzw. Datenbanktabellen in “Objektform” ab. Alle anderen Implementierungen der Logik landen direkt im `models` Verzeichnis. Ein solches Domänenobjekt könnte folgendermaßen aussehen:

// models/entities/user.js
module.exports = function (/* possible EM or DAO injection */) {
   // EM or DAO ...

   return function () {
      // private attributes
      var _id = null,
          _username = null,
          _password = null;

      // constructor
      (function construct() {
          // ...
      }());

      // private methods
      function privateMethod () {}

      // return public object with public functions
      return {
         // typical getter for all attributes
         getPropertyObject: function () {
            return {
               id: _id,
               username: _username,
               password: _password
            };
         },
         setPropertyObject: function (propertyObject) {
            _id = propertyObject.id;
            _username = propertyObject.username;
            _password = propertyObject.password;
         },
         loadUser: function (username, password) {
            // use DAO with ORM or implement manually
         },
         persistUser: function () {
            // use DAO with ORM or implement manually
         }
      };
   };
}

Wie man am obigen Code erkennen kann, ist es ganz einfach ein Domänenobjekt/Entity zu erstellen. Auffallend ist hier, dass das Model extra noch einmal in einer Funktion gewrappt ist, welche dann zurückgegeben wird. Vorteil dieser Implementierung ist ein eigener Scope für Entity Managers oder Data Access Objects, da diese normalerweise nicht als Attribute des Models abgebildet werden sollten. Objekte von diesem Model können dann ganz bequem aus einem Controller erstellt werden:

// controllers/index.js
module.exports = function (/* EM or DAO */) {
   // require model
   var User = require('../models/entities/user.js')(/* EM or DAO */);

   return {
      // ...
      checkLoginAction: function (req, res) {
         var usernameGiven = req.body.username,
             passwordGiven = req.body.password;

         var user = new User();
         user.loadUser(usernameGiven, passwordGiven);
      }
   };
};

Views mit Underscore

Wer mit Jade als Templateengine nicht zufrieden ist, kann auch jede andere verwenden, die mit Express kompatibel ist. Für mich hat die Templateengine von Underscore gewonnen, da ich normale HTML Dateien als Views verwenden kann und dort meine minimale Logik integrieren kann. Wer ebenfalls Underscore verwenden will, muss seine `package.json` Datei um zwei Module erweitern, 1. Underscore und 2. Consolidate (wird benötigt um Underscore in Express zu integrieren):

// package.json
{
   "name": "myApp",
   "version": "0.0.1",
   "private": true,
   "scripts": {
      "start": "node app.js"
   },
   "dependencies": {
      "express": "3.4.0",
      "underscore": "*",
      "consolidate": "*"
   }
}

Danach sollte man nochmal `npm install` ausführen, um die Node Module, die noch fehlen, nachzuinstallieren (in diesem Fall Underscore und Consolidate). In der `app.js` muss man danach lediglich noch die View Engine updaten:

// app.js
var cons = require('consolidate');

app.engine('html', cons.underscore);
app.set('view engine', 'html');

Fazit

Express liefert ein sehr schlankes und umfangreiches Framework für Web Applikationen. Man kann mit Leichtigkeit Requests und Reponses bearbeiten, Routen definieren, Sessions und Cookies verwalten und vieles mehr. Durch die Flexibilität des Frameworks ist es auch sehr einfach zu erweitern. Express zwingt den Entwickler nicht sich an die Struktur zu halten, sondern erlaubt die Funktionen in eigenen, neuen und erweiterten Architekturen einzusetzen.

The post Business Applications mit Node.js und Express appeared first on Mobile USTP MKL.

Ghost ist eine mobile-freundliche Open Source Blogging Platform und spezialisiert sich laut Homepage einzig auf “Publishing”. Es ist auf Grund des offenen Quellcodes von jedem sehr einfach anzupassen und zu erweitern, sei es beim Erstellen von Themes oder gar zusätzlichen Featuremodulen.

Was Ghost jedoch wirklich ausmacht, ist das Konzentrieren auf das Bloggen selbst. Der Macher von Ghost, John O’Nolan, war selbst langjähriger Programmierer bei WordPress und gibt im Introduction Video an, WordPress wäre nicht mehr eine reine Blogging Software, sondern habe sich in den letzten Jahren stark geändert und wäre demnach mehr zu einem CMS für voll-funktionierende Homepages geworden. Ghost jedoch ist anders – mit Ghost sollen sich Autoren nur kurz mit der Konfiguration befassen und sich dann endgültig und ausschließlich dem Schreiben von Artikeln widmen können.

Einziges Manko: Ghost ist ein Node App und läuft somit nur auf Servern, die Node.js installiert haben. Dieses Problem sieht anfangs kleiner aus als es ist, denn die meisten Web Hoster bieten hauptsächlich PHP an. Sogar Ruby musste sich auf Grund der geringen Anfrage seinen Platz bei den Hostern erkämpfen. Da die Popularität von Node.js jedoch rasant steigt, ist es wohl nur eine Frage der Zeit, bis mehr Web Hoster anfangen Node.js Interpreter auf ihren Plattformen anzubieten. Abhilfe schafft hier beispielweise ein virtueller Server, auf welchem Programme wie PHP oder Node.js selbstständig und frei installiert werden können – allerdings muss man für diese etwas tiefer in die Geldbörse greifen.

The post Ghost – Open Source Blogging leicht gemacht appeared first on Mobile USTP MKL.