Archiv für den Monat: März 2014

Synology Diskstation als Git-Server

Meine Synology Diskstation nutze ich hauptsächlich als Fileserver und für Backups. Es ist also naheliegend für meine Entwicklungen auch ein Git-Repository auf der NAS aufzusetzen. Die Installation und Konfiguration ist an sich ganz einfach. Die Suche nach der Dokumentation ist allerdings mühselig, da die notwendigen Informationen auf mehrere Quelle verteilt sind.  Genau das ändert sich mit folgendem Post.

Ziel ist es auf der Diskstation ein Git-Repository zu installieren, auf dem sich die Benutzer via ssh verbinden können. Die Authentifizierung geschieht über Key-Files.

Git Installation über die Synology Diskstation Admin-Oberfläche

Git lässt sich einfach über die Administrationsoberfläche der Diskstation installieren. Dazu muss man nur den Dienst Git im Paketmanager auswählen und auf installieren klicken. Nach dem Download steht Git auf der Konsole zur Verfügung.

Git Dienst im Synology Diskstation Pakeketzentrum

Git User Anlegen

Als nächstes lege ich einen neuen Benutzer „git“ an. Hierzu verwende ich auch die Administrationsoberfäche: Systemsteuerung > Benutzer > erstellen.

Der Benutzer benötigt Zugriff auf die Konsole via ssh. Leider kann ich das nicht über die Administrationsoberfläche zuweisen. Dazu logge ich mich als root via ssh auf die Synology Diskstation ein. Über die Konsole bearbeite ich die Datei /etc/passwd (z.B. mit dem vi):

Diskstation> vi /etc/passwd

und ändere die Zeile:

git:x:1028:100::/var/services/homes/git:/sbin/nologin

in:

git:x:1028:100::/var/services/homes/git:/bin/ash

Nach dem Speichern kann sich der git Benutzer via ssh auf der Diskstation anmelden.

Git Repository anlegen

Genau das tue ich  jetzt um das Git Repository anzulegen.

strolzm@localhost:~$ ssh git@[IpDIskstation]

Ich befinde mich im Home-Verzeichnis des Git Users auf der Diskstation. Hier erstelle ich ein neues Verzeichnis, in dem wir ein leeres Git-Repository anlegen:

Diskstation> mkdir repos 
Diskstation> cd repos
Diskstation> mkdir firstRepo
Diskstation> cd firstRepo
Diskstation> git init --bare

Authorisierung über SSH-Keys

Jetzt bin ich schon ziemlich weit. Ich könnte schon einen lokalen Klon des Repositorys erzeugen, müsste mich aber mit dem Passwort des git-Benutzers authentifizieren. Das möchte ich natürlich nicht bei jedem Zugriff machen und lege deshalb ssh-Keys an. Unter Linux geschieht das über:

strolzm@localhost:~$ ssh-keygen 
Generating public/private rsa key pair.
Enter file in which to save the key (/home/strolzm/.ssh/id_rsa):

Ich speichere die Schlüssel wie vorgeschlagen im [home]/.ssh-Verzeichnis. Den öffentlichen Schlüssel erzeuge ich im Anschluss:

strolzm@localhost:~$ ssh-keygen -p
Enter file in which the key is (/home/strolzm/.ssh/id_rsa):

Den öffentlichen Schlüssel kopiere  ich auf die Diskstation. Falls es noch nicht existiert, lege ich dort das Verzeichnis [home]/.ssh an

Diskstation> mkdir .ssh

Mit folgendem Befehl kopiere ich den öffentlichen Schlüssel in die Datei .ssh/authorized_keys auf der Diskstation. Wenn diese Datei schon existiert und Schlüssel enthält, muss der neue Schlüssel natürlich angehängt werden. In dem Fall verwendet man am einfachsten einen Texteditor

strolzm@localhost:~$ scp .ssh/id_rsa.pub git@[IpDiskstation]:/volume1/homes/git/.ssh/authorized_keys

Git Repository Klonen

Ich habe es geschafft und kann das angelegte Git Repository auf meiner lokalen Maschine klonen:

strolzm@localhost:~$ git clone ssh://git@[IpDiskstation]:/volume1/homes/git/repos/firstRepo

Quellen

Die Suche nach der Doku für die einzelnen Schritte hat eigentlich am längsten gedauert. Ich habe mich an folgenden Seiten durchgehangelt. Falls ich etwas vergessen habe, kann es sicher auf einer der Seiten gefunden werden. Noch schöner wäre ein Hinweis an mich, sodass ich die Beschreibung ergänzen kann.

Grunt – Projektorganisation mit JavaScript

Mein Script für die Skillmatrix hat inzwischen schon über 40 Zeilen Code und eine Abhängigkeit zu jQuery. Es kommt wahrscheinlich aus meiner Vergangenheit als Java-Entwickler aber ich werde den Drang nicht los, die beiden Dateien in eine sinnvolle Projektstruktur betten zu wollen. Dazu gehört die Organisation des Quellcodes ein Build-Prozess, Stylechecks mit JSHint und am liebsten auch ein Bisschen Testing.

Bei der Suche nach der Befriedigung dieser Bedürfnisse bin ich recht schnell bei Grunt gelandet. Bei dem Vortrag „Let Grunt do the work, focus on the fun!, von Dirk Ginader auf Slideshare stieß ich dann auf folgende Folie die mich vollends überzeugte:

slide-infrastructure

Grunt ist ein TaskRunner für JavaScript und erinnert im ersten Augenblick an Ant, dann an Maven und schließlich an Gradle. Es vereint also die Möglichkeit seinen Buildvorgang in Tasks abzubilden, die benötigten Resourcen und Tools automatisch zusammenzustellen und die Buildumgebung per Scripting einfach auf die gewünschte Projektstruktur abzubilden. Scriptsprache ist hier selbstverständlich JavaScript.

grunt-logo

Die Installation erfolgt über den PackageManager von NodeJs mit Hilfe einer einzigen Zeile:

npm install -g grunt-cli

Hiermit steht eine Art Laufzeitumgebung zur Verfügung. Der eigentliche TaskRunner wird dann pro Projekt aufgesetzt. Somit werden mehrere Projekte mit unterschiedlichen Grunt-Versionen ermöglicht. Die Definition oder Konfiguration des Projekts erfolgt in zwei Dateien, die im Quellverzeichnis liegen:

  1. package.json Die Datei,beschreibt das Projekt und dessen Abhängigkeiten . Hier stehen beispielsweise Name, Versionsnummer, die verwendete Grunt-Version oder Autor und Lizenz. Die Dateien können per grunt-init bzw. npm-init automatisch erzeugt werden.
  2. Gruntfile.js Ein JavaScript, das die Tasks definiert und konfiguriert. Hier wird beschrieben welche Tasks für den Buildprozess überhaupt zur Verfügung gestellt werden und wo die Tasks, (z.B. JSHint) die benötigten Quelldateien finden. Innerhalb der Gruntfile.js kann man auf Attribute der package.json zugreifen um beispielsweise Verzeichnis- oder Dateinamen aus dem Projektnamen oder der Versionsnummer abzuleiten.

Anleitungen zur Konfiguration der Dateien findet man im Getting Started Guide von Grunt. Am Beispiel der Skillmatrix wird der Aufbau der package.json deutlich:

{
  "name": "skillmatrix",
  "version": "0.0.1",
  "devDependencies": {
    "grunt": "~0.4.4",
    "grunt-contrib-jshint": "~0.6.3",
    "grunt-contrib-nodeunit": "~0.2.0",
    "grunt-contrib-uglify": "~0.2.2"
  },
  "description": "A webclient for the skillmatrix.",
  "main": "Gruntfile.js",
  "dependencies": {
    "grunt": "~0.4.4"
   },
  "author": "Matthias Strolz"
}

Nachdem Projekt und Abhängigkeiten in der package.json definiert wurden, kann man die benötigten Plugins über den NodeJS Packagemanager in sein Projekt importieren:

npm install

Die Dateien werden dann im Verzeichnis node_modules innerhalb des Projekts abgelegt.

In einem meiner letzten Posts habe ich die Funktionsweise des Stylecheckers JSHint beschrieben. Die Konfiguration, die ich dort für mein Projekt in Sublime angelegt habe, möchte ich gerne auch beim bauen mit Grunt verwenden. Dazu setze ich die option jshint: true in der Konfiguration des Tasks jshint. Die Tasks uglify, oder concat zum Zusammenführen und Minimieren der einzelnen Quelldateien, habe ich aus folgendem Beispiel entfernt.

module.exports = function (grunt) {
  "use strict";
  grunt.initConfig({
    pkg: grunt.file.readJSON('package.json'),
...
    jshint: {
    // define the files to lint
    files: ['Gruntfile.js', 'src/<%= pkg.name %>/*.js'],
    options: {
      jshintrc : true
    }
  },
...
  grunt.loadNpmTasks('grunt-contrib-jshint');
...
  grunt.registerTask('test', ['jshint']);
};

Inzwischen habe ich eine projektartige Struktur. Mein Quellcode liegt im Verzeichnis src/skillmatrix. Es gibt einen Build Prozess, der automatische Stylechecks durchführt, meine Dateien zusammenführt und minimiert. Fehlen eigentlich nur noch automatisierte Tests. Selbstverständlich gibt es auch hierfür Grunt-Tasks.

Der Preis für diese Struktur sind die Konfigurationsdateien package.json, Gruntfile.js und .jshintrc sowie die Grunt-Module die ebenfalls innerhalb des Projektverzeichnisses abgelegt werden.

JSHint und JSLint – JavaScript Codequality

Bei meinen ersten eigenen JavaScript Gehversuchen mit der Skillmatrix muss ich feststellen wie sehr sich das Entwickeln von JavaScript und Java unterscheidet. Die starre Typisierung und Java ermöglicht ein recht komfortables Refactoring, das somit toolgetützter Teil des Entwicklungsprozesses werden kann. Bei JavaScript scheint mir das schon ein wenig schwerer. In Eclipse kann das Ausmaß dieser Schwierigkeiten an dem Unterschied der Einträge im Refactoring-Contextmenü des JavaScript Editors gemessen werden.

jslint

Bei der Suche nach der Lösung dieses Problems stößt man innerhalb kürzester Zeit auf JSLint oder, wenn es etwas stylisher aussehen darf, auf den Doppelgänger JSHint. Hierbei handelt es sich weniger um eine IDE oder ein Refactoring-Tool, sondern um eine Art Stylecheck für JavaScript-Quellcode. JSLint testet die etablierten Codeconventions. Im einfachsten Fall kann man sein Skript einfach via Copy und Paste in das Online-Formular kopieren und auf unterschiedlichste Fehler prüfen lassen. Die Spannbreite reicht von vergessenen Leerzeichen und Kommas über Variablen, die nicht verwendet werden oder sich im Falschen Scope befinden bis hin zu missverständlichen Verzweigungen oder unerwünschten Notationen.

jshint

Somit hilft JSLint nicht direkt beim Entwickeln des Codes, meckert aber wenn das Ergebnis nicht ganz optimal ist. Schön wäre es, wenn diese Prüfung regelmäßig schon während der Entwicklung gemacht wird. Geht das? Klar geht das. Bei der Suche nach dem passenden Eclipse-Plugin wird man bei jshint-eclipse fündig. Wie erwartet wird man sofort nach der Installation in der gewohnten Strenge auf mögliche Probleme in seinem Script hingewiesen. Die Art der Prüfungen kann man über das Menü (Windows > Preferences > JSHint > Configuration) entsprechend er JSHint Options leicht anpassen.

An dieser Stelle möchte ich gestehen, dass die Codebeispiele aus der Skillmatrix bereits mehrere JSLint-Durchläufe hinter sich haben. Wie viele Punkte JSLint gefunden hat, bleibt aber mein Geheimnis.

Ich bin mir trotzdem noch nicht ganz sicher ob ich bei der Entwicklung von JavaScript bei Eclipse bleibe oder auf einen Texteditor umsteige. Deshalb probiere ich von Anfang an auch leichtgewichtigere Alternativen wie Sublime aus. Eine Anleitung zur Integration von JSHint in Sublime findet man im Blog von Exratione.

Die Refactoring Tools von Eclipse aus der Java-Welt vermisse ich immer noch. Ich kann mir vorstellen, dass diese Sehnsucht verstärkt wird, wenn sich die Skripte über mehrer Dateien und Verzeichnisse erstrecken. Trotzdem beruhigt JSLint bzw. JSHint, da so Codequalitäts-Standards gesichert werden können, die über einfache Syntaxchecks hinausgehen. Hier hilft wahrscheinlich eine Art Continious Integration Produkt auf JavaScript-Ebene. Aber das ist ein Thema für einen anderen Post.

Mit jQuery und JavaScript zur Skillmatrix

Es wird Zeit für mein erstes kleines JavaScript-Projekt. Die theoretischen Grundlagen sind gelegt. Bei Codecademy habe ich ausführlichst geübt. Ich muss also nur noch loslegen.

Für meine Website http://freelance.matthias-strolz.de, die ich zur Bewerbung als Java/J2EE Freelancer benutze, möchte ich meine Fertigkeiten und Kenntnisse neben meinen Projekten auch in einem kleinen Diagramm darstellen. Ich will das mal als Skillmatrix bezeichnen.

Skillmatrix Screenshot

Die unterschiedlichen Fertigkeiten (Skills) werden in einem einfachen JSON File angelegt.

"skillGroups" : [
 {
  "id" : "programmingLanguages",
  "title" : "Programmierung",
  "skillBlocks" : [
   {
    "title" : "Programmiersprachen",
    "skills" : [
     {
      "title" : "Java"
     },
     {
      "title" : "Groovy"
     },
     {
      "title" : "JavaScript"
     },
...

Per JavaScript sollen jetzt die Informationen aus dem JSON ausgelesen und auf meiner Homepage angezeigt werden. Für das Laden des JSON und die DOM Manipulation verwende ich jQuery. Für die meisten Funktionen meines Skripts kann ich auf Basisfunktionen von jQuery zurückgreifen. Zum Abholen der Daten genügen folgende Zeilen:

$.getJSON("../json/skills.json", function (data) {
   var parent = $("#col3_content"), skillGroupIds = [];
   $.each(data.skillGroups, function (key, skillGroup) {
     processSkillGroup(skillGroup, parent);
     skillGroupIds.push(skillGroup.id);
   });
   fadeInSkillGroups(skillGroupIds, 0);
});

In der Funktion processSkillGroup werden die Skill-Gruppen und Blöcke und die Skills selbst ausgelesen in HTML gepackt und in den div mit der id col3_content gehängt. Anschließend sorgt die Methode fadeInSkillGroups dafür, dass die einzelnen Gruppen nach und nach auf der Seite eingeblendet werden. Für das Auge soll ja auch was dabei sein.

Die Umwandlung von JSON in HTML erfolgt durch die Erzeugung von Strings mit HTML-Tags, die dann über jQuery in einen bestimmten div gehängt werden.

function processSkillGroup(skillGroup, parent) {
  parent.append('<div id="' + skillGroup.id + '" style="display:none;"><h2>' + skillGroup.title + '</h2></div>');

   $.each(skillGroup.skillBlocks, function (key, skillBlock) {
     processSkillBlock(skillBlock, $('#' + skillGroup.id));
   });
 }

Bei der Kombination von JavaScript Quellcode und HTML Tags muss ich dann zum ersten mal schlucken. Da kommen Erinnerung an die dunkle Epoche der Servlet Programmierung hoch. Vielleicht gibt es ja eine JavaScript Templating Sprache, denke ich mir und nehme mir vor auf die Suche zu gehen.

Wenn die ganzen Divs erzeugt und im DOM angekommen sind sollen sie nacheinander eingeblendet werden. Über einen rekursiven Aufruf der jQuery-Funktion fadeIn ist das ein Kinderspiel.

function fadeInSkillGroups(skillGroupIds, index) {
  if (index + 1 < skillGroupIds.length) {
    $('#' + skillGroupIds[index]).fadeIn('fast', function () {
      fadeInSkillGroups(skillGroupIds, index + 1);
    });
  } else {
    $('#' + skillGroupIds[index]).fadeIn('fast');
  }
}

Mit ungefähr 40 Zeilen JavaScript-Code ist es also Möglich mit ein paar visuellen Effekten JSON in HTML zu verwandeln. Das empfinde ich schonmal als angenehme Erkenntnis. Weniger angenehm ist der Tool-Support bei der Entwicklung mit Eclipse. Code-Completion sind im eingebauten JavaScript-Editor Fehlanzeige wie ein anständiger Syntaxcheck. Refactorings sind ebenfalls deutlich unkomfortabler als bei der Java bzw. J2EE Entwicklung. Es klappt schon recht schnell und unkompliziert ansprechende Ergebnisse mit JavaScript zu erzielen. Aufgrund des mangelnden Toolings insbesondere bei Eclipse mache ich mir ein wenig Sorgen um die Aufrechterhaltung der Code-Qualität. Aber sicher gibt es hierfür Lösungen, mit denen ich mich in meinem kommenden Blogbeitrag beschäftigen kann.