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.

Ein Diplom an der Codecademy

Nachdem ich mich über Oliver Zeigermanns Buch „JavaScript für Java-Entwickler“ technologisch dem Browser angenährt hatte, wollte ich das erlernte natürlich vertiefen. Neben den theoretischen Grundlagen fehlt mir vor allem die Praxis. Bei der Suche nach einigen Tutorials bin ich auf die Codecademy gestoßen.

Codecademy_logo

Auf der Plattform kann man die Kurse:

  • HTML & CSS
  • jQuery
  • JavaScript
  • PHP
  • Python
  • und Ruby

besuchen. Learning by Doing lautet hier die Devise. Pro Technologie gibt es einen Satz aufeinanderfolgender Übungen. Je nach Vorkenntnissen kann der Einstieg selbst gewählt werden. Ich entscheide mich bei Null anzufangen und starte mit der ersten Übung aus dem Kurs JavaScript. Der Aufbau der Turorials besteht aus einer sehr einfachen Aufgabenstellung, die in einem Online Editor gelöst werden will. Erlerntes wird in mehren Schritten vertieft und muss immer wieder angewendet werden.

codecadamyCourse

Der Einstieg ist simpel: Variable, Kommentare, Schleifen Verzweigungen, Arrays…  Alles in allem müssen keine großen Hürden übersprungen werden. Langweilig wird es aber trotzdem nicht, weil es vom Verständnis bis zur Lösung nur weniger Minuten und einiger Zeilen Code bedarf. Darüber hinaus wird man mit unzähligen Badges belohnt: Für die erste Übung, den ersten abgeschlossenen Kurs, 10 Übungen pro Tag und so weiter. Ich muss gestehen, dass ich durchaus auf das Belohnungsschema anspringe.

Bald betrete ich mit den Übungen so etwas wie Neuland und übe die JavaScript Objektnotation, anonyme Funktionen, Prototypen und die Varianten der Objekterzeugung und Manipulation. Für den Abschluss mein JavaScript Codecademy Zertifikat benötige ich einen Tag. Ich bin zufrieden und schließe auch noch die HTML & CSS und die jQuery Klasse ab. Nachdem ich die Grundlagen erarbeitet und geübt habe, widme ich mich den Web-Project angeboten. Dort werden in einigen etwas komplexeren Aufgaben JavaScript und HTML zusammengeführt.

codeCademyBadges

Meine Badges füllen inzwischen den ganzen Monitor und so langsam habe ich den Eindruck dass ich für tieferes Wissen und kniffligere Aufgaben bereit bin. Wenn ich möchte kann ich meine Eigenen Tutorials auf der Plattform anbieten oder mich in einer der vielen Gruppen mit anderen Entwicklern zu fortgeschrittenen Themen austauschen.

Ich habe den Eindruck, dass ich mich mit meinen Kenntnisse gerne ich der echten virtuellen Welt austoben möchte. Anregungen kann man sich auch hier bei der Codecademy holen. So gibt es weitere Turorials für APIs von Diensten wie z.B. Youtube oder Soundcloud.

Die Codecademy war für mich ein super Einstieg in die Praxis von JavaScript und JQuery. Ich habe den Eindruck mir die Grundlagen beider Technologien praktisch angeeignet zu haben. Vor allem aber hat es Spaß gemacht, so dass ich den Besuch der Kurse zur Nachahmung empfehlen kann.

JavaScript für Java-Entwickler

In der Zentralbibliothek der Hamburger Bücherhallen stolperte ich unter den Neuerscheinugen zufälligerweise über ein Buch, das wie für mich gemacht zu sein schien. Ich hatte gerade H.G. Wells‘ „Die Tür in der Mauer“ gelesen, zu dessen Rückgabe ich die Bücherhallen überhaupt aufgesucht hatte. Da es in der Kurzgeschichte um das Nutzen von Möglichkeiten geht, die sich unerwartet bieten, schaute ich mir das Buch etwas genauer an.

Es trägt de Titel „JavaScript für Java-Entwickler“, geschrieben von Oliver Zeigermann, 2013 erschienen bei entwickler.press. Als ich auf dem Waschzettel folgende Zeilen las, war ich überzeugt und nahm das Buch mit:

„Zielpublikum sind Java-Entwickler, die sich so einfach und schmerzfrei wie möglich der Sprache JavaScript nähern wollen oder müssen. Deshalb wird alles weggelassen, was man als Java-Entwickler entweder sowieso weiß oder nicht wissen muss.“

Wenn man das alles weglässt kommt man auf 132 Seiten, die erfüllen was auf dem Buchrücken versprochen wird. Nach einer kurzen Einleitung geht’s in fünf Kapiteln, von den Grundlagen zu fortgeschrittenen Themen wie objektorientierte Entwurfsmuster oder JSON.

Ich habe das Buch von vorne bis hinten durchgelesen. Entsprechend des Kenntnisstandes ist es aber auch möglich Kapitel auszulassen, bzw. zu überspringen. Trotz oder vielleicht wegen seiner Kürze bietet das Buch einen einfachen Einstieg in die Sprache JavaScript ohne in die Oberflächlichkeit abzudriften. Lebendig wird es durch die vielen Codebeispiele und die regelmäßigen Hinweise auf Best Practices der JavaScript Entwicklung. So werden unterschiedliche IDEs und Entwicklungstools besprochen. Themen wie die Projektorganisation, Refactorings und UnitTests, ohne die die Java-Entwicklung kaum noch vorstellbar sind, kommen natürlich auch nicht zu kurz.

Für mich war das Buch ein gelungener Einstieg in ein Themenfeld, das für mich mit vielen Vorurteilen belegt war. Durch den Schritt durch die Tür in der Mauer habe ich einen Eindruck für das Wesen der Scriptsprache JavaScript bekommen und Lust gewonnen mich ein Bisschen damit auszutoben.

Zu kaufen gibt es das Buch JavaScript für Java-Entwickler bei Amazon.

Setting Up OpenMRS in Eclipse Kepler

Nach meinen OpenMRS Codejam bei ThoughtWorks möchte ich eine lokale Entwicklungsumgebung bei mir aufsetzen. Bei den Mitarbeitern von ThoughtWorks ist IntelliJ die IDE der Wahl. Ich habe bisher hauptsächlich mit Eclipse gearbeitet und möchte das weiterhin tun. Da die Projekt-Organisation via Maven gesteuert wird, sehe ich keine größeren Hindernisse, die einen Versuch ausschlössen. Außerdem gibt es eine offizielle Anleitung für die Einrichtung von OpenMRS unter Eclipse.

Die Softwarevoraussetzungen erfülle ich. Ich habe Ubuntu mit einem JDK 6. Git und MySQL habe ich auch schon installiert. Ich benutze Eclipse Kepler in der J2EE Variante. Hinzugefügt habe ich Plugins eGit, m2e, sowie die m2e Connectoren für Git und wtp. Bevor ich zu Eclipse komme, brauche ich erst mal den Quellcode auf dem OpenMRS-Git-Repository auf GitHub. Einen Klon bekomme ich per Git auf dem Terminal über:

git clone https://github.com/openmrs/openmrs-core.git

Anschließend richte ich mir einen neuen Workspace namens openmrs ein. Dazu lege ich einfach ein neues Verzeichnis an, das ich beim nächsten Start von Eclipse als Workspace auswähle.

mkdir openmrsmkdir openmrs

Nach dem Start von Eclipse importiere ich die Projekte aus meinem Klon des Git-Repositorys. Dazu wähle ich im Menü:

> File > Import > Maven > Existing Maven Projects into Workspace

Als Quellverzeichnis für den Import wähle ich das Verzeichnis in dem der oben erwähnten Klon liegt. Bei mir ist das:

~/git/openmrs-core

Ich importiere alle Projekte, die mir der Assistent nach Auswahl der Quelle anbietet.

Import Existing Maven Projects openMRS

Import Existing Maven Projects openMRS

Nach Klick auf Finish beginnt der Import und eine Menge Mavenkram passiert im Hintergrund. Gleichzeitig werde ich aufgefordert ein neues Plugin zu installieren:

"m2e connector for build-helper-maven-plugin"

Ich folge den Anweisungen und starte Eclipse wie empfohlen neu, nachdem das Plugin installiert wurde und der Import der Projekte abgeschlossen ist. Wie erhofft konnten alle Projekte angelegt werden:

  • openmrs
  • openmrs-api
  • openmrs-release-test
  • openmrs-test
  • openmrs-tools
  • openmrs-web
  • openmrs-webapp

Allerdings werden noch einige Probleme und mehrere Tausend Warnings angezeigt. Die Fehler kann ich beheben indem ich die tools.jar in die BuildPath Einträge des Projekts openmrs-tools hinzufüge. Dort liegen die benötigten Klassen der Packages com.sun.tools… und com.sun.javadoc… für das ShouldTaglet.

import com.sun.tools.doclets.Taglet;
import com.sun.javadoc.*;
import java.util.Map;

/**
 * Taglet for @should annotations.
 */
public class ShouldTaglet implements Taglet {

Bei den Warnings handelt es sich um Unschönheiten im Quellcode. Sie sind wohl der verteilten Projektstruktur und den wenig strengen Code-Guidelines geschuldet. Ich möchte das Projekt erstmal zum Fliegen kriegen und werde mich um die Probleme später kümmern.

Ich konfiguriere einen Maven-Build, indem ich mit der rechten Maustaste auf das Top-Projekt openmrs und dort auf:

Run As > 2 Maven Build ...

klicke. Als goals tippe ich „clean install“ ein und lege los. Es dauert zwar ein paar Minuten, dann läuft der Build aber erfolgreich durch. Jetzt wird’s ernst. Ich starte einen zweiten Build, diesmal auf dem Projekt webapp mit dem goal jetty:run .

Die Webapp wird gestartet. Ich erreiche sie unter:

http://localhost:8080/openmrs/index.htm

und werde zum Installations-Assistenten weitergeleitet. Ich entscheide mich für die simple Installation. Hier muss ich nur einen MySQL Benutzer angeben, der die Datenbank und die Tabellen anlegt. Auch das mache ich natürlich gerne, der Rest läuft von selbst. Nach der Installation lande ich auf dem Login Screen und nach der Eingabe von admin / Admin123 bin ich am Ziel:

openMRSWelcomeScreen

OpenMRS Codejam bei ThoughtWorks

Es gibt wohl viele Möglichkeiten die Welt ein Bisschen besser zu machen, indem man ein wenig seiner freien Zeit und seines Know Hows einbringt. Als Softwareentwickler fällt das im Allgemeinen recht leicht, da man sich an einem von unzähligen gemeinnützigen Open Source Projekten beteiligen kann. Ich habe sowohl Zeit als auch Muse interessante und hilfreiche Projekte zu unterstützen. Der Zeitaufwand für das Projektsetup, die Einrichtung der Entwicklungsinstanz und die Einarbeitung in die fachlichen Themen der Anwendung empfinde ich aber als eine große Hürde.

OpenMRS-logo

Diese Hürde nimmt die Firma Thoughtworks bei ihren Codejams. Thoughtworks unterstützt die Open Source Plattform OpenMRS. Die Software dient zur Erfassung medizinischer Daten und erleichtert die Verwaltung von Krankenakten und somit die Diagnostik und Behandlung in Gebieten mit einer niedrigen medizinischen Infrastruktur. OpenMRS ist seit Jahren in vielen Ländern der Welt im Einsatz. Da es kostenlos ist und niedrige Anforderungen an die benötigte Hard- und Software stellt, wird es auch in vielen Entwicklungs- und Krisenländern verwendet. Die Codejams finden alle paar Monate z.B. in der Hamburger Niederlassung von Thoughtworks statt. Ich besuchte die Veranstaltung am 11.Januar 2013.

Die Einladung ließ viel Interpretationspielraum für den Inhalt des Termins. Die Angabe, dass jeder ohne Vorkenntnisse vorbeischnuppern kann, empfand ich aber als sehr sympathisch. Um 10:00 Uhr gings dann also los. Außer mir nahmen noch fünf andere Gäste und ebenso viele Mitarbeiter von ThoughtWorks an dem Termin teil. Nach einer kurzen Vorstellungsrunde bekamen wir eine kleine Einführung in das System, dessen Verwendung, der Projektorganisation und der technischen Architektur. Die Web-Anwendung setzt auf dem gängigen Technologiestack, bestehend aus SpringMVC und Hibernate auf. In der Präsentationsschicht werden JSPs verwendet deren HTML-Output mit JQuery abgerundet wird.

OpenMRS Technologieübersicht

Nach der Präsentation teilten wir uns zum Pair-Programming auf. Jeder Newbie suchte sich dazu einen alten Hasen von ThoughtWorks. Die meisten Besucher klonten sich das OpenMRS Repository von GitHub und versuchten eine Entwicklungsumgeb zum Laufen zu bringen. Ich arbeitete mit Marvin an dessen Maschine zusammen und konnte somit gleich mit der Entwicklung beginnen. Marvin ist Student und ist über ein OpenMRS-Codejam auf ThoughtWorks aufmerksam geworden. In den kommenden Wochen geht seine Bewerbung für eine Festanstellung in die heiße Phase. Ich drücke die Daumen.

Im OpenMRS-Ticket-System gibt es einige Aufgaben für Einsteiger. Bei den meisten handelt es sich um kleinere Bugs, Übersetzungen, Dokumentation oder Verbesserungen der Codequalität. Wir schnappten und einen einfachen JavaScript-Bug und konnten ihn recht schnell lösen. Also suchten wir uns ein etwas komplexeres Problem. Wir fanden einen Bug, der seine Wurzeln in der Applikationslogik hatte und verbrachten den Rest des Tages damit ihn zu finden und zu lösen. Bevor unsere Änderungen in das Produkt einfließen, müssen noch OpenMRS-Core-Entwickler den Pull-Request akzeptieren.

tw-logo

Der Codejam war das erste Event auf dem ich mit anderen Entwicklern, freiwillig und auch völlig unvorbereitet an einem Projekt arbeitete. Durch die Einführung bei ThoughtWorks und die Mischung aus uns Neulingen und Entwicklern, die die Software kannten, gelang es doch einigermaßen schnell die ersten Tickets zu bearbeiten. Neben der technischen Unterstützung schaffte ThoughtWorks eine angenehme und produktive Umgebung und stellte Getränke und natürlich Pizza.

Der nächste Codejam findet am 15.März in Hamburg statt. Ich bin dabei.