In Anschluss an meinen letzen Artikel zum Bau eines Node.js-Moduls, möchte ich noch kurz mein Vorgehen bei der Verwendung von Travis CI erklären. Auch wenn ich als Autor von Jenkins Kurz & Gut natürlich bevorzugt Jenkins für kontinuierliche Integration verwende, kann es doch ganz nett und sinnvoll sein einen Dienst wie Travis CI zu nutzen. Gerade Open Source-Projekte sind hier bestens geeignet, vor allem wenn sie auf Github liegen!

Vor einigen Tagen habe ich mein erstes NPM-Paket für Node.js erstellt: Leipzig.js. Es handelt sich dabei um einen sehr rudimentären Client für die API Leipzig. Neben dem offensichtlichen Zweck des Moduls wollte ich endlich auch mal in die Node.js Modulentwicklung einsteigen und mir ansehen, wie NPM funktioniert.

Um Teil 1 und Teil 2 der Reihe zu ergänzen nun der dritte Teil zum Thema ActiveAdmin. Um genau zu sein möchte ich heute auf Quick Filter eingehen. Dabei handelt es sich um vordefinierte Suchanfragen die direkt über den Grids gerendert werden. Klassisches Beispiel für einen solchen Filter ist etwa die Anzeige aller veröffentlichten Seiten innerhalb eines CMS.

In meinem Beispiel soll es ein User-Model geben, dass über die boolesche Eigenschaft active ausdrückt, ob ein Nutzer-Account durch einen Admin freigegeben wurde oder nicht. Um alle nicht aktivierten Accounts schnell aufzulisten und somit den Workflow für die Suche nach “zu prüfenden Nutzern” zu verbessern, bietet sich ein Quick Filter an.

Nachdem ich im ersten Teil meiner ActiveAdmin-Reihe auf die Installation und die grundlegende Verwendung eingegangen bin, möchte ich mich heute kurz den Menüs widmen.

Wenn man via rake eine neue Admin-Resource erstellt, legt ActiveAdmin automatisch einen neuen Menü-Punkt, mit dem Namen der Entität als Label, an. Wenn man allerdings viele Entitäten/Models hat, wird dieses Menü recht schnell sehr breit und unübersichtlich. ActiveAdmin bietet hierfür die Möglichkeit an, Menüpunkte ineinander zu verschachteln - automatisch generierte Dropdowns inklusive. Und so geht’s:

Angenommen es gibt die beiden Models Interviews und Interview_Questions. Jedes Interview kann also beliebig viele Fragen zugewiesen bekommen. Da diese beiden Entitäten doch sehr stark voneinander abhängen, sollen sie einen gemeinsamen Menüpunkt bekommen.

1
2
3

ActiveAdmin.register Interview do
  menu :parent => "Interviews", :priority => 1
end

1
2
3

ActiveAdmin.register InterviewQuestion do
  menu :parent => "Interviews", :priority => 2
end

Wer bereits mit Django entwickelt hat, für den sind schnell aufgesetzte, hochfunktionale und schicke Admininterfaces nichts neues. Doch auch in der Ruby-Welt gibt es das ein oder andere ernstzunehmende Gem, das ähnliche Features bereitstellt. Nebenbei bemerkt finde ich diese Trennung von den einzelnen Gems in Ruby besser gelöst als das Out-of-the-Box-Adminterface von Django. Auch wenn es schön ist, direkt nach der Einrichtung eines Projektes Zugriff auf diese Möglichkeiten zu haben, scheint mir die Auslagerung wesentlich sauberer und schicker.

Doch zurück zu den Kontrahenten. Aktuell scheinen zwei Gems um den Platz des besten Backends zu kämpfen: ActiveAdmin und RailsAdmin. Nachdem ich mir beide etwas näher angeschaut hatte, fiel meine Entscheidung auf ActiveAdmin. Es sieht nicht nur wesentlicher schicker aus - es ist auch noch super einfach zu bedienen. Auch komplexe Backends sind in wenigen Stunden erledigt. Folgend werde ich kurz auf die Installation sowie einige Beispiele eingehen.

In diesem Post möchte ich kurz auf das Indizieren einer MongoDB-Collection eingehen und welche Performanceauswirkungen dies haben kann. Zum Test habe ich 1 Mio. Datensätze nach dem Schema { _id: ..., value : i } durch eine for-Schleife (ja Mongo kann mit reinem Javascript bedient werden) angelegt.

1

$ mongo performancetest

1

> var i = 1; for (i = 0; i < 1000000; i++) { db.Example.save({ value: i }); }

Dieser Vorgang kann je nach Rechner einige Sekunden dauern. Danach kann man das Ergebnis mit einem Aufruf von count überprüfen.

1
2

> db.Example.count()
1000000

Um jetzt die zeitlichen Unterschiede zwischen einer Query ohne Index und einer mit zu ermitteln, bietet sich der Profiler an, welcher über folgende Methode gestartet werden kann.

Als ich diese Woche ein neues Projekt deployt habe ist mir aufgefallen, dass mein guter alter Debian-Root-Server noch auf MySQL 5.0 läuft - die Applikation allerdings 5.1 voraussetzt. Upgrade? Klar doch!

Leider lies sich der MySQL-Server nach dem Upgrade nicht mehr hochfahren, was zur Folge hatte das mehr als zehn meiner Webseiten nicht mehr erreichbar waren:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

mysql-server-5.1 (5.1.49-3) wird eingerichtet ...
Stopping MySQL database server: mysqld.
Starting MySQL database server: mysqld . . . . . . . . . . . . . . failed!
invoke-rc.d: initscript mysql, action "start" failed.
dpkg: Fehler beim Bearbeiten von mysql-server-5.1 (--configure):
  Unterprozess installiertes post-installation-Skript gab den Fehlerwert 1 zurück
dpkg: Abhängigkeitsprobleme verhindern Konfiguration von mysql-server:
  mysql-server hängt ab von mysql-server-5.1; aber:
  Paket mysql-server-5.1 ist noch nicht konfiguriert.
dpkg: Fehler beim Bearbeiten von mysql-server (--configure):
  Abhängigkeitsprobleme - verbleibt unkonfiguriert
Fehler traten auf beim Bearbeiten von:
  mysql-server-5.1
  mysql-server

Ein kurzer Blick in das syslog zeigte folgenden Eintrag:

Git ist schon lange zum Liebling der Entwicklergemeinde avanciert. Doch viele arbeiten nur mit den Git Grundbefehlen oder nutzen nicht deren reichhaltigen Fundus an Flags und Attributen.

Ein schönes Beispiel dafür ist die Verwendung von git log. Die meisten werden es nur einsetzen um die letzten Commits und deren Committish abzufragen. Doch man kann es auch einsetzen um eine mehr oder weniger grafische Repräsentation der Historie zu erhalten. Für Freunde der Kommandozeile sicherlich ein interessantes Feature:

1

$ git log --pretty=oneline --abbrev-commit --graph --decorate

Das Ergebnis könnte dann wie folgt aussehen.

Der MongoDB-Wrapper Mongoose ist der De-facto-Standard, wenn man eine MongoDB zusammen mit Node.js einsetzen will. Doch Mongoose kann mehr als nur simple Attribute zu beherbergen, die lediglich auf eine Collection in der Datenbank mappen.

Methoden

Wer den Funktionsumfang eines Models erweitern will, kann dies über Methoden tun. Diese werden in einer eigenen Eigenschaft methods festgehalten. Im folgenden Beispiel werden über die Methode findNamesakes alle Namensvetter einer Person gefunden und durch den Callback zugänglich gemacht.

1
2
3
4
5
6
7
8
9

var Schema = require('mongoose').Schema;
var PersonSchema = new Schema({
    firstname:  String
  , lastname:   String
});

PersonSchema.methods.findNamesakes = function findNamesakes(cb) {
    return this.find({ firstname: this.firstname }, cb);
};

Node.js - Veteran TJ Holowaychuk hat seinem bekannten Testing-Framework Expresso einen Bruder namens Mocha entwickelt. Während Expresso eher im Bereich Test-Driven-Development angesiedelt war und sich an Ruby’s Test::Unit orientiert hat, besticht Mocha durch Behaviour-Driven-Development Manieren und schickt sich an das RSpec der Node.js-Welt zu werden.

Nach der Installtion über den Paketmanager NPM kann das Testen auch schon losgehen.

1

$ npm install -g mocha

Testen

Wie beim Vorbild werden einzelne Funktionen wie describe beschrieben und dann via it auf deren Richtigkeit geprüft. Tests sollten per Konvention im Ordner test liegen. Ein simples Beispiel sieht folgendermaßen aus:

1
2
3
4
5
6
7
8

describe('Array', function(){
  describe('#indexOf()', function(){
    it('should return -1 when the value is not present', function(){
      [1,2,3].indexOf(5).should.equal(-1);
      [1,2,3].indexOf(0).should.equal(-1);
    })
  })
})