IOException.de » web

Benachrichtigungen für die Piratenpads skripten

Michael Müller — Tue, 27 Dec 2011 12:51:43 +0000

Die Piratenpads sind eine bequeme, kostenfreie Möglichkeit um kollaborativ an Texten zu arbeiten oder etwa Ideen zu sammeln. In letzter Zeit nutze ich den Service mit einigen anderen Leuten sehr exzessiv. Über die verschiedenen Pads in verschiedenen Teams habe ich aber inzwischen einfach den Überblick verloren. Um herauszufinden, ob es irgendwo Neuerungen gibt muss ich alles manuell abklappern und mich bei jedem einzelnen Team einloggen. Ich bin der Ansicht, dass man genau solche Aufgaben nach Möglichkeit immer automatisieren sollte.

Deswegen habe ich einen Notificationservice für die Piratenpads geschrieben. Das Skript loggt sich ein, fragt die aktuelle Version des Dokuments ab und speichert diese lokal zwischen. Beim nächsten Überprüfen (idealerweise als Cronjob) wird die lokale Kopie mit dem online-Original verglichen. Gibt es eine Differenz wird eine E-Mailbenachrichtigung mit dem diff versandt.

Um das Ganze zu Skripten habe ich node.js mit der Bibliothek request verwendet:

Request is designed to be the simplest way possible to make HTTP calls. It support HTTPS and follows redirects by default.

Tolle Sache! Ohne HTTPS-Support kommen wir eh nicht weit, bei einigen Pads ist der Zugriff auf HTTPS eingeschränkt. Außerdem muss man sich dank der Bibliothek nicht um das mühsame Parsen von “Set-Cookie” Feldern kümmern. request übernimmt die Cookies standardmäßig einfach global für zukünftige Requests.

Um die Session zu initialisieren, also sich vor dem Login einen Cookie zu holen, sieht der Code etwa so aus:

var request = require('request');
var base = 'https://foo.piratenpad.de';

(function initiateSession() {
	request.get(base, function (error, response, body) {
		if (!error && response.statusCode == 200) {
			login();
		}
	});
})();

Die Loginfunktion habe ich zusammengebaut, nachdem ich den kompletten Skriptablauf im Firefox durchgespielt habe und alle Requests mittels des (unheimlich praktischen) Live HTTP Headers Add-ons aufgezeichnet habe.

function login() {
	var options = {
			url: base + '/ep/account/sign-in',
			form: {'email': 'john@doe.de', 'password' : 'mypw'}
	};

	request.post(options, function (err, res, body) {
			request.get(base + '/' + acc.padId, function (err, resp, body) {
				// get the latest version of the pad document
				var linkToLatestVersion = body.match(/[\w\d\/\-\.]*(latest')/gi);
				linkToLatestVersion = linkToLatestVersion[0].replace("'", '');

				getLatestDocument(linkToLatestVersion);
			});
		}
	);
}

Die aktuelle Version des Dokuments lässt sich dann mit einem einfachen GET-Request abfragen:

function getLatestDocument(linkToLatestVersion) {
	request.get(base + linkToLatestVersion, function (err, resp, body) {
		var start = body.search('id="padcontent">') + 'id="padcontent">'.length;
		var end = body.search("");
		var padContent = body.substring(start, end);

		// strip all tags and entities
		padContent = padContent.replace(/(<[^>]+>)|(&[#\w]+;)/gi, '');

		console.log(padContent.trim());
	});
}

Das Ganze zusammengefasst als ordentliches, sauber konfigurierbares, Projekt gibt es hier auf GitHub. Das Skript kann sehr einfach für ähnliche Aufgaben wiederverwendet werden. Als Anregung: Beispielsweise wäre es möglich das Uni Hochschulportal anzuzapfen um E-Mailbenachrichtigungen zu versenden, wenn neue Prüfungsergebnisse eingetragen sind.

Update: Ich habe noch die Möglichkeit hinzugefügt, Benachrichtigungen für Änderungen an dem Inhalt hinter einer URL zu konfigurieren (im Ordner simple-webpage/). Ich benutze das als simple Lösung für Seiten, die keinen RSS-Feed bereitstellen.

Sopra-Projekt: Routenplaner für das Gelände der Uni Ulm

Michael Müller — Thu, 01 Sep 2011 13:46:12 +0000

An der Uni Ulm muss jeder Bachelorstudent in einem Informatik / Informatik verwandten Studiengang das Sopra absolvieren. Das ist ein umfangreiches Softwareprojekt, das sich über zwei Semester erstreckt. Im ersten Semester steht dabei die Erfassung von Anforderungen, die Planung und das Pflichtenheft im Vordergrund. Das passiert in einem Team aus drei Studenten. Im zweiten Semester werden zwei Teams zusammengelegt, so dass fortan sechs Leute an der Implementierung arbeiten.

Alle Teams, die am Sopra teilnehmen, müssen dasselbe Projekt implementieren, wobei die Projekte jedes Jahr wechseln. Dieses Jahr war die Aufgabe von Grund auf einen Routenplaner für die Universität zur erstellen. Die Ausgangsbasis waren die Baupläne der Uni, die vom Bauamt zur Verfügung gestellt wurden.

Einige Problemstellungen des Projekts waren eine besondere Herausforderungen. Beispielsweise müssen handelsübliche Straßen-Routenplaner nicht mit fünf Stockwerken die übereinander liegen zurecht kommen.

Zum Routing: Algorithmen für Routingprobleme (Dijkstra, Bellman-Ford, etc.) verwenden üblicherweise einen gewichteten Graphen. Unser Team hat sich dafür entschieden eine graphenbasierte NoSQL-Datenbank zu verwenden: Neo4J. Da wir vorhatten einen Routeplaner zu entwickeln bot es sich einfach an eine Datenbank zu verwenden die inhärent schon auf einer Graphenstruktur aufbaut und somit viele Probleme — wie das Routing zwischen Knoten — schon im Vornherein löst.

Routingalgorithmen auf relationalen Datenbanken können recht hässlich werden. Für einige andere Teams war das eines der Kernprobleme.

Man sollte Technologien nie deswegen auswählen, weil es eben die einzige Technologie ist die man kennt.
Stattdessen sollte eine Technologie, ein Werkzeug, gewählt werden, weil es sich am Besten für die Aufgabe eignet.

Der Routenplaner sollte webbasiert realisiert werden. Wir haben uns für Vaadin als Web-Framework entschieden. Vaadin setzt auf GWT auf und ermöglicht es Web-Applikationen in Java zu schreiben, als würde man eine Swing-Applikation entwickeln. Java Code wird durch einen Cross-Compiler in JavaScript, HTML & CSS übersetzt. Die Arbeit mit dem Framework hat ziemlich gut funktioniert, es lassen sich sehr schnell vorzeigbare Ergebnisse erstellen.

Wir haben außerdem eine Desktop-Applikation für das Bearbeiten und Hochladen von Kartenmaterial geschrieben. Da wir die Aufgaben im Vornherein aufgeteilt hatten war ich hier aber nur beteiligt als es um die Synchronisation mit der Webapp ging. Dafür haben wir Git verwendet (siehe auch den Blogbeitrag “Git als Update-Mechanismus“).

Weitere erwähnenswerte Technologien: Für den PDF-Druck haben wir LaTeX verwendet. Aus einer generierten *.tex Datei wird eine PDF erstellt und an den Browser zurückgegeben. Wir haben mittels node.js das Uni-Adressbuch gescraped um so vernünftig einen vollständigen Datensatz in die Datenbank zu bekommen.

Die erstellen Projekte werden nicht produktiv eingesetzt werden, es wird aber an einer Musterimplementierung gearbeitet. Diese wird später eventuell auch auf den Terminals, die auf dem Unigelände verteilt sind, laufen.
Allgemein war es ziemlich interessant mal in einem größeren Team an einem umfrangreicheren Projekt zu arbeiten. Man lernt einige Dinge über die Arbeit im Team und verschiedene Technologien. Insbesondere lernet man aber wo die eigenen Stärken liegen.

Einfache Visualisierung von Geodaten – Teil 2: Leaflet & jquery.couch.js

Benjamin Erb — Tue, 30 Aug 2011 09:48:49 +0000

Im vorherigen Teil haben wir gesehen, wie man Geodaten mithilfe von CouchDB abspeichern kann. Da diese Datenbank zugleich ein Webserver ist und die Daten im JSON-Format gespeichert werden, eignet sie CouchDB auch gut für AJAX-Abfragen. Hierfür gibt es eine auf jQuery aufbauende Library namens jquery.couch.js, die von den AJAX-Requests abstrahiert und direkt browser-seitige Interaktionen mit der Datenbank ermöglicht.

Im diesem Beitrag soll gezeigt werden, wie man mit der offenen Karten-Library Leaflet und jquery.couch.js geographische Daten aus CouchDB heraus auf einer Karten anzeigen kann.

Beispiel-Visualisierung von ulmapi.de, ebenfalls basierend auf CouchDB und Leaflet.

Wir verwenden die CouchApp aus dem ersten Teil weiter, und fügen zu den bisherigen Map/Reduce Views noch statische HTML- und Javascript-Dateien hinzu (im _attachments Ordner), die dann im Browser abgerufen werden können. Beim Aufruf dieser Webseite wird ein HTML-Grundgerüst übertragen, sowie eine JavaScript-Datei, die beim Aufruf die eigentlichen Datensätze via jquery.couch.js aus der CouchDB nachlädt.

Als Mapping-Library verwenden wir Leaflet, eine Open-Source Bibliothek für Kartendarstellungen im Browser. Leaflet abstrahiert von verschiedenen Kartenprovidern und erlaubt es somit, unterschiedliche Datenquellen zu verwenden, wie zum Beispiel auch Bing Maps oder Cloudmade. Letzteres ist ein Service, der auf Basis der Open Street Map Daten Kartenkacheln mit individuellen Stilen rendert und hostet – für Visualisierungen oft sehr hilfreich, da reguläre Karten meist zu viele Karteninformationen enthalten oder farblich überladen sind. In unserem Fall haben wir einen einfach Graustufenkarte gewählt. Leaflet selbst lässt sich relativ leicht verwenden, es muss eine CSS-Datei sowie eine JavaScript-Datei importiert werden, und ein div-Block im HTML enthalten sein, worin später die Karte gerendert werden soll. Somit sieht unser HTML-Gerüst zu Beginn so aus:

Es werden jQuery, jquery.couch.js und die Leaflet-Libs geladen, und die letzte importierte JavaScript-Datei soll nun unseren Code zum initialisieren der Karte und dem Laden der Daten aus der CouchDB enthalten. Zunächst erstellen wir eine Karte und rendern sie, sobald die Seite vollständig geladen wurde (jQuery Callback für document.ready):

$(document).ready(function(){

		var cloudmadeUrl = 'http://{s}.tile.cloudmade.com/[YOUR_API_KEY]/33481/256/{z}/{x}/{y}.png';
		var cloudmadeAttribution = 'UlmApi.de / Shape Files: Stadt Ulm (cc-by-sa), Map data © 2011 OpenStreetMap contributors, Imagery © 2011 CloudMade';
		var cloudmade = new L.TileLayer(
			cloudmadeUrl, {
				maxZoom : 18,
				attribution : cloudmadeAttribution
		});

		var map = new L.Map('map', {
			center : new L.LatLng(48.399976,9.995399),
			zoom : 12,
			layers : [ cloudmade ],
			zoomControl : false
		});
});

In der cloudmadeUrl muss für Cloudmade Karte ein korrekter API-Key angegeben werden, der nächste Parameter im Pfad identifiziert den Kartentyp. Beim Initialisieren der Karte wird dann die ID des divs angeben, bei uns ‘map’. Nun sollte unsere Karte bereits dargestellt werden, nachdem wir die CouchApp neu deployen (außerhalb des Fokus dieses Artikels, mehr dazu auf couchapp.org).

Was nun noch fehlt, ist das Nachladen der Geodaten aus der CouchDB und die Anzeige auf der Karte. Hierfür verwenden wir jquery.couch.js als Wrapper für die AJAX-Requests gegen CouchDB und die GeoJSON-Funktionalität von Leaflet:

$.couch.db('database_name').view('design_doc_name/view_name', {

	success: function(data){
		if(data && data.rows && data.rows.length){

			var geoJsonLayer = new L.GeoJSON();

			for(var i = 0;i
Das obige Snippet sollte im vorherigen Code hinter der Erzeugung der Karte eingefügt werden. Es ruft von der Datenbank ‘database_name’ den View ‘view_name’ des Design-Dokuments ‘design_doc_name’ auf, und iteriert bei erfolgreicher Abfrage über alle Zeilen. Von jeder Zeile wird dabei die geometry-Property zu einem GeoJSON-Layer hinzugefügt, der am Ende an die Karte übergeben wird. Da unser View aus Teil 1 bereits GeoJSON generiert, und Leaflet nativ GeoJSON lesen und darstellen kann, ist das Hinzufügen von Geodaten auf die Karte sehr einfach.
Hier noch ein paar weiterführende Links mit vertiefenden Inhalten zu den einzelnen Themen:

Leaflet Reference
CouchApp
Diplomarbeit von Lena Herrmann über Webanwendungen mit CouchDB und CouchApp

Einfache Visualisierung von Geodaten – Teil 1: CouchDB/GeoCouch

Benjamin Erb — Tue, 09 Aug 2011 15:43:01 +0000

Die Hochschulgruppe Open Data Ulm hat es sich zur Aufgabe gemacht, offene und öffentliche Daten rund um die Region Ulm zu aggregieren, aufzuarbeiten und zu visualisieren. Näheres zu diesem Projekt sowie bereits gesammelte Datensätze gibt es unter UlmApi.de

Für unser Vorhaben habe ich als Persistenzlösung die dokumentenorientierte Datenbank CouchDB gewählt, da sie für uns mehrere interessante Features bietet:

schemalos: Anders als relationale Datenbanken benötigen schemalose Datenbanken keine im Voraus fest definierte Struktur der Einträge. Für unsere Geodaten ist dies sehr hilfreich, da außer einer ID und den Geodaten noch beliebige zusätzliche Daten pro Eintrag mitgespeichert werden können.
JSON: Für die Speicherung strukturierter Daten stellt dieses Format eine leichtgewichtige Alternative zu XML dar.
webbasiert: Die Datenbank ist zugleich ein Webserver und der Zugriff auf die Daten läuft somit über HTTP.
verteilt/replizierend: Ein wichtiges Konzept von CouchDB ist die einfache aber mächtige Replikation zwischen verschiedenen Instanzen. Im Kontext unserer offenen Datensammlungen ermöglicht dies, dezentralte Kopien der Daten anzulegen, diese lokal zu editieren oder erweitern und wieder auf unsere Hauptdatenbank zu laden.
Attachments: Neben strukturierten Daten lassen sich auch ganze Dateien speichern. Dies ist vor allem für archivierte Rohdaten in proprietären Formaten interessant.
CouchApps: Neben der Speicherung der Daten sind vor allem einfache Anwendungen interessant, die diese visualisieren oder aufbereiten. Das Konzept der CouchApps ermöglicht es uns, simple Webanwendungen direkt auf der Datenbank zu deployen und verfügbar zu machen.
räumliche Indizes: Dank Volker Mische besitzt CouchDB einen zusätzlichen Index (GeoCouch), der statt eindimensionaler B-Bäume zweidimensionale R-Bäume benutzt. Damit lassen sich Dokumente mit räumlichen Daten abspeichern, indizieren und effizient abfragen.

Von der Stadt Ulm haben wir als ersten Datensatz Shapefiles der Ulmer Stadtteile und Stadtviertel bekommen. Diese wurden zunächst vom Ausgangsformat (Gauss-Krueger-Shapefiles) in das GeoJSON-Format mit WGS84-Koordinaten konvertiert. Mithilfe eines kleinen node.js Skriptes wurden die einzelnen Shapes dann als Dokumente auf die Couch geladen.

Ein Dokument hat hierbei folgende Form (Originaldokument):

{
   "_id": "ul-st14",
   "_rev": "1-797187e292d93b6d661ca8f7fec3f6c9",
   "type": "stadtteil",
   "name": "Weststadt"
   "geometry": {
       "type": "Feature",
       "properties": {
           "identifier": "ST 14",
           "name": "Weststadt"
       },
       "geometry": {
           "type": "Polygon",
           "coordinates": [
               [
                   [
                       9.981459,
                       48.395751
                   ],
                   …
              ]
           ]
       }
   },
   "creator": "Stadt Ulm",
   "license": {
       "name": "Creative Commons - Namensnennung-Weitergabe unter gleichen Bedingungen 3.0 Deutschland (CC BY-SA 3.0)",
       "link": "http://creativecommons.org/licenses/by-sa/3.0/de/"
   },
}

Die _id bestimmt das Dokument eindeutig, das _rev Feld ist für die Versionskontrolle verantwortlich. Als ID haben wir einen internen Identifier der Stadt genommen und noch mit einem “ul” Präfix versehen. Der Rest des Dokuments kann frei strukturiert werden. In unserem Fall verwenden wir noch ein type Feld, durch das wir später Dokumente unterschiedlichen Typs unterscheiden können (z.B. stadtteil oder stadtviertel). Das geometry Feld (hier gekürzt) enthält die geografischen Daten im GeoJSON-Format. Die sonstigen Felder beschreiben noch den Urheber und die Lizenz der Daten sowie den Namen des Eintrags.

Nun ist die Datenbank gefüllt, später sollen aber die Daten auch wieder abgefragt werden können. Als “NoSQL” Datenbank bietet CouchDB hierfür aber keine SQL-Statements an, stattdessen muss man mithilfe von MapReduce beschreiben, wie aus den Daten Indizes gebildet werden sollen:

function(doc) {
	if (doc.type) {
		if(doc.type === 'stadtviertel'){
		    emit(['stadtviertel', doc._id], {
		    	'geometry' : doc.geometry,
		    	'label' : "Stadtviertel "+doc.name+"
ID: "+doc._id+"
(Stadteil "+doc.stadtteil+")"
		    });
		}
		else if(doc.type === 'stadtteil'){
		    emit(['stadtteil', doc._id], {
		    	'geometry' : doc.geometry,
		    	'label' : "Stadtteil "+doc.name+"
ID: "+doc._id
		    });
		}
	}
};

Damit erzeugen wir eine sortiere Liste von Schlüssel-Wert-Paaren. Der Schlüssel ist selbst wieder komplex und besteht aus zwei Teilen. Der erste Teil ist der Typ, der zweite Teil die ID des Dokuments. Damit kann man später durch die sogenannte View Collation Abfragen durchführen, die sich auf einen bestimmtem Typ beschränken (zur Wiederholung: ohne SQL gibt es hier auch kein WHERE Statement). In diesem Fall werden bisher nur Dokumente des Typs stadtteil oder stadtviertel eingetragen, und als Wert eines Eintrages wird bereits die spätere Nutzung auf einer Karte vorbereitet – es werden die Geodaten sowie ein Label indiziert. Damit lassen sich nun schon Stadtteile/Stadtviertel abfragen.

Ergänzt man dies noch um einen räumlichen Index, so werden auch räumliche Abfragen ermöglicht. Hierfür werden in den Index als Schlüssel die Geodaten (unverändert im GeoJSON Format) eingetragen, den Wert selbst bliebt leer, da das Feld _id sowieso eingetragen wird und vorest keine weiteren Daten mehr benötigt werden:

function(doc){
	if(doc.geometry && doc.geometry.geometry){
		emit(doc.geometry.geometry, null);
	}
};

(Das etwas merkwürdig anmutende doc.geometry.geometry entstand einerseits dadruch, dass unser Feld mit dem GeoJSON-Objekt geometry heißt, das GeoJSON-Objekt selbst aber komplex ist und nur in einem Teil davon die eigentlichen Geodaten hinterlegt sind.)

Mithilfe dieses Index lässt sich nun bei einem gegebenen geografischen Raum überprüfen, welche Objekte darin enthalten sind. Also zum Beispiel ausgehend von einer Koordinate, ob sie sich in Ulm befindet und wenn ja, in welchem Stadtteil/Stadtviertel.

Im nächsten Teil wird näher betrachtet, wie die nun abgespeicherten und indizierten Geodaten im Browser auf einer Karte dargestellt werden können, und zwar direkt aus CouchDB heraus.

Präsentieren mit HTML5-Foliensätzen

Benjamin Erb — Fri, 05 Aug 2011 11:48:24 +0000

Kurzversion: HTML5 Foliensatz, basierend auf einem Google Template, das zusätzlich Notizen und einen Presenter Mode bietet: Demo / Code

Nicht nur die Frage, wie man richtig präsentiert (Stichwort Zen vs. Death by PowerPoint), sondern auch die Frage, mit welchen Anwendungen man präsentiert, ist oft umstritten. Ich persönlich konnte mich bisher mit Powerpoint und Konsorten eher wenig anfreunden – vor allem Typografie und Einschränkungen bei der Gestaltung waren problematisch. Als Alternative habe ich bisher oft LaTeX Beamer verwendet, was allerdings je nach visueller Komplexität auch oft relativ zeitaufwendig ist, sich aber zumindest bei Grafiken in Vektorformaten und mathematischen Inhalten auch schnell auszahlt.

HTML5-basierte Foliensätze

Mit dem Aufkommen von HTML5 entstand eine zusätzliche Möglichkeit. Dank der neuen Multimedia-Tags wie und sowie mächtigeren CSS Stilen bietet HTML nun die Grundlagen für browser-basierte Präsentationen. Mittlerweile gibt es hierfür auch schon mehrere Templates:

Noch mehr Alternativen gibt es in dieser Auflistung. Ein weiteres sehr schönes Beispiel ist ein Foliensatz zu HTML5, der selbst quasi eine Technologiedemonstration enthält: http://slides.html5rocks.com

Der Vorteil von HTML-basierten Präsentationen ist die hohe Anzahl von Medien (u.a. auch SVG, Flash Videos oder ganze Webseiten als IFrames), die man einbetten kann. Ein einfaches, weitläufig bekanntes Markup ermöglicht das schnelle Erstellen von Folien, und mit einer Kombination aus HTML, CSS und JavaScript lassen sich dennoch auch komplexe Spezialfunktionen realisieren.

Mir persönlich hat das html5slides Template ganz gut gefallen, das Google entwickelt und für die Google I/O Slides eingesetzt hat. Da das Template unter einer Apache License veröffentlicht wurde, habe ich zunächst damit begonnen, es an das Uni Ulm Corporate Design anzupassen. Außerdem hatte ich ein paar kleine Änderungen am Code vorgenommen, um zum Beispiel eine Nummerierung der Folien zu ermöglichen.

Presenter Mode?

Prinzipiell war das Ergebnis schon mal akzeptabel, allerdings wurden die oft genannten Probleme bei solchen HTML-Foliensätzen schnell offensichtlich – fehlende Notizen für den Vortragenden und nur eine Ausgabe.

Eher durch Zufall bin ich auf ein anderes Konstrukt gestoßen, dass seit HTML5 Cross-Frame-Communication erlaubt, also den Austausch von Nachrichten zwischen zwei verschiedenen Frames (mit einigen Einschränkungen): window.postMessage()

Die Möglichkeit, zwischen Frames zu kommunizieren, ist natürlich auch ideal dafür, Daten zwischen Frames zu synchronisieren. Übertragen auf zwei verschiedene Präsenationsframes ermöglicht dies beim Weiterschalten der Folien in einem Frame, den zweiten Frame zu aktualisieren. Schematisch sieht das so aus:

(CC-BY-NC) Icons by picol.org / w3.org

Im Hauptfenster kann per Tastendruck ein zusätzliches Popup geöffnet werden (1). Das neue Popup öffnet die gleiche URI der Präsentation und wird auf dem Bildschirm des Vortragenden platziert. Schaltet der Vortragende nun im Hauptfenster weiter zu nächsten Folie, so erzeugt dies ein Nachricht an das zweite Frame (2), das dann ebenfalls weiterschaltet.

Eine weitere Ergänzung war die Unterstützung von Notizen als Overlay über die Folien. Kombiniert mit dem Dual-Screen-Ansatz ermöglicht dies, dem Publikum die Folien zu zeigen, dem Vortragenden auf einem zweiten Bildschirm die Folien plus den verfügbaren Notizen.

Ausführliche Beispiele mit Code gibt es in einer Beispielpräsentation, den kompletten Code auf github: https://github.com/berb/html5slides-uulm

Auf der Feature Wishlist steht noch ein alternativer CSS-Stylesheet für den Druckexport. Außerdem ein Tool, dass externe Daten wie Bilder per Base64 encoding als Data URI integriert und JavaScript sowie Stylesheets inline einbindet, sodass die Präsentation als einzelne HTML5 Datei ohne externe Abhängigkeiten abgespeichert werden kann.

Warum wir eine Wave brauchen

matou — Mon, 14 Mar 2011 02:02:29 +0000

Das Problem

E-Mail ist alt und kaputt. Es gehört durch modernere Kommunikationsarten ersetzt. Warum? Was erwarten wir von Kommunikation über das Internet?

Confidentiality, Integrity, Authentication
Perfect Forward Secrecy (PFS)
Plausible Deniability (PD)
Asynchrone und synchrone Kommunikationsmöglichkeit
Gruppenkommunikation
Kollaboration
Multimediale Kommunikation
Dezentrale Struktur

Wenn wir von Verschlüsselung sprechen, dann ist damit Ende-zu-Ende-Verschlüsselung gemeint und nicht die Verschlüsselung der Transportwege. Das Gleiche gilt für Integrity und Authentication.

Wir können E-Mails verschlüsseln und digital signieren (z. B. durch Verwendung von OpenPGP). Leider kann dann für immer und von jedem bewiesen werden, dass wir diese Nachricht geschrieben haben. Ein weiteres Problem entsteht, wenn einer der Keys in falsche Hände gerät. Dann sind sämtliche bisher für ihn verschlüsselten Daten kompromittiert.

E-Mail ist langsam und immer asynchron. E-Mail-Verkehr kostet unnötig Zeit.[0]

E-Mail ist nicht kollaborativ.

E-Mail-Anhänge ermöglichen zwar die Übertragung multimedialer Inhalte, sind aber unglaublich ineffizient und ressourcenfressend.

Was gibt es also für Alternativen? Wie kann besser kommuniziert werden?

Soziale Netzwerke sind Privacy-Desaster.

Instant Messaging erfüllt die meisten Zwecke. Bei vielen Protokollen ist sowohl asynchrone als auch synchrone Kommunikation möglich. Confidentiality, Integrity, Authentication, Perfect Forward Secrecy und Plausible Deniability wird durch Verwendung von OTR[1] erreicht (allerdings nur bei Kommunikation mit einem Partner). Einige Protokolle erlauben Gruppenkommunikation durch Chaträume oder multimediale Kommunikation, wie das Übertragen von Dateien oder Video-/Audio-Telefonie.

Warum reichen bestehende Instant-Messaging-Systeme nicht aus? Was fehlt uns?

Unterhaltungen in Echtzeit
Flexibles Hinzufügen von Teilnehmern zur Gruppenkommunikation
Verbessertes Sharing und Darstellung von Multimediainhalten
Verschlüsselte, möglicherweise asynchrone, Gruppenkommunikation
(mit PD und PFS)

Die ersten drei Punkte kann Googles Wave[2,3]. Das Problem der verschlüsselten Gruppenkommunikation mit den beschriebenen Bedingungen ist leider darin bisher nicht gelöst worden. Zudem existieren keine zufriedenstellenden Clients für Wave.

Wir wollen, dass die Infrastruktur nicht von einem einzigen Knotenpunkt abhängig ist. Dezentrale Struktur wird von den Protokollen, die E-Mail bzw. Wave zugrunde liegen, unterstützt. Fast alle IM-Dienste erlauben diese nicht.

Die Lösung

Wir sehen mehrere Lösungsansätze.

Komplett neues Protokoll mit Implementierung und Infrastruktur

Auch bekannt als: „Das Rad neu erfinden“. Machen wir nicht. Das Rad gibt es schon. Dieser Ansatz wäre sehr aufwändig und würde sich schwer etablieren.

Verwendung bestehender Protokolle

Bedingung ist, dass das Protokoll offen und leicht erweiterbar ist. Hier halten wir nur XMPP für sinnvoll. Der Vorteil dieser Lösung ist, dass genau die gewünschten Features implementiert werden können und keine Kompromisse notwendig sind. Voraussichtlich wird bereits bestehende Infrastruktur verwendet werden können.

Erweiterung von Wave

Wave hat bereits die meisten Features, welche wir uns wünschen. Verschlüsselung fehlt aber und es existieren keine guten Clients.

Der Plan

Wir evaluieren die letzten beiden Lösungsansätze und implementieren dann die sinnvollste Lösung. Dazu müssen wir zunächst XMPP und das Google Wave Federation Protocol verstehen.

Auf jeden Fall werden wir einen Client schreiben, der im Vergleich zu bestehenden Clients besser bedienbar ist und unsere beschriebenen Anforderungen erfüllt. Für Legacy-Clients ist eine (teilweise) Umsetzung der Features, beispielsweise durch Plugins, denkbar.

Die Unzufriedenheit mit vorhandenen Kommunikationsmöglichkeiten und die Idee diese zu verbessern schlummert schon seit einiger Zeit in uns. Hiermit möchten wir die Sache ins Rollen bringen. Stay tuned!

–nico, phil, matou

[0] http://www.heise.de/newsticker/meldung/Unternehmen-will-Mitarbeitern-die-E-Mail-abgewoehnen-1184596.html
[1] http://www.cypherpunks.ca/otr/
[2] http://wave.google.com/
[3] http://www.waveprotocol.org/

XMPP Multiuser Chat Bot

matou — Sat, 05 Mar 2011 16:10:05 +0000

Multiuser Chats stellen eine gute Möglichkeit dar mit vielen Leuten gleichzeitig zu kommunizieren. Ich selbst nehme regelmäßig über MUCs an Entwicklermeetings teil oder bespreche mit Freunden, was es so zu besprechen gibt. Und natürlich macht chatten auch viel Spaß :-)

Neulich hatten wir während eines solchen Chats die Idee, dass wir doch unseren WG-Server am Chat teilnehmen lassen könnten, damit dieser uns z.B. mit Zitaten aus Fernsehsendungen unterhält oder wir über ihn die Musik in der Wohnung steuern können. Seit wir begonnen haben den ersten MUC-Bot zu implementieren, kommen immer wieder neue Ideen auf, was ein Bot so alles tun könnte. Zum Beispiel als Wörterbuch fungieren oder Kochrezepte fürs Abendessen vorschlagen.

Damit grundlegende Funktionalität nicht für jeden Bot neu geschrieben werden muss, habe ich begonnen ein kleines Framework zu entwickeln, dass sich um den XMPP-Teil des Bots kümmert und häufig benötigte Funktionen realisiert. Das Framework ist in python geschrieben.

Im Folgenden beschreibe ich die Mucbot-Klasse, die einen einfachen Bot darstellt. Um den Eintrag übersichtlich zu halten lasse ich einige Dinge weg, die nicht wesentlich sind. Daher wird der hier gepostete Code nicht lauffähig sein. Für die komplette Version schaut einfach auf github vorbei.

# Der Bot verwendet xmpppy () um mit einem
# Jabber-Server zu kommunizieren.
import xmpp

# Wir brauchen Regular Expressions um in empfangenen Nachrichten nach Keywords
# zu suchen, auf die reagiert werden soll.
import re

# Das time Modul wird verwendet um Verzögerungen einzubauen. Z.B. falls der Bot
# nach einer bestimmten Zeit etwas sagen soll.
import time

# Der Bot erbt von Thread. Er kann also im Hintergrund gestartet werden, während
# das Programm noch etwas anderes tut.
from threading import Thread

class Mucbot(Thread):

# Es ist einiges an Initialisierung notwendig. Der Bot braucht eine Jabber-ID und
# ein dazu gehörendes Passwort, um sich damit am Server anmelden zu können. Da
# es ja ein MUC-Bot ist, braucht er außerdem einen Raum, dem er sich anschließen
# wird. Optional kann man ihm noch einen Namen geben, eine Liste von Zitaten,
# die er gelegentlich zitiert und ein Dictionary mit Keywords auf die er
# reagieren soll mit dazugehörenden Reaktionen. Die Keywords sind dabei als
# Reguläre Ausdrücke gegeben.
    def __init__(self, jid, pwd, room, botname='', roompwd='', quotes=[],
            minwait=-1, maxwait=-1, reactions={}, delay=3):

        # Kein expliziter Botname? -> Verwende die Node der Jabber-ID
        if botname == '':
            botname = jid.getNode()

        # […]
        # hier werden alle übergebenen Parameter in der Mucbot-Instanz
        # gespeichert, um diese später noch verwenden zu können

        # Um Nachrichten schnell nach Schlüsselwörtern durchsuchen zu können
        # werden alle Regulären Ausdrücke compiliert.
        for key in self.reactions.keys():
            self.reactions[re.compile(key)] = self.reactions.pop(key)

        # Jetzt kommt die Verbindung zum Server. Zuerst erstellen wir ein
        # xmpp.Client Objekt und verbinden uns mit dem angegebenen Server.
        self.client = xmpp.Client(jid.getDomain(), debug=[])
        self.client.connect()

        # Um auf ankommende Nachrichten reagieren zu können, müssen wir
        # entsprechende Handler registrieren.
        self.client.RegisterHandler('message', self.msg_rcv)
        self.client.RegisterHandler('presence', self.pres_rcv)

        # Die Authentifizierung am Server:
        self.client.auth(jid.getNode(), pwd, resource=jid.getResource())

        # Und schlussendlich das Betreten des Raums:
        p = xmpp.Presence(to='%s/%s' % (room, botname))
        p.setTag('x', namespace=xmpp.NS_MUC).setTagData('password', roompwd)
        p.getTag('x').addChild('history', {'maxchars':'0', 'maxstanzas':'0'})
        self.client.send(p)

# Möchte der Bot etwas sagen, wird vom xmpp-Modul die xmpp Stanza zusammengebaut
# und an den Chatraum gesendet.
    def say(self, msg):
        m = xmpp.Message(to=self.room, body=msg, typ='groupchat')
        self.client.send(m)

# Wenn der Bot eine Nachricht empfängt, wird folgende Methode aufgerufen:
    def msg_rcv(self, sess, msg):

        # Wir ignorieren Nachrichten, die wir selbst verschickt haben.
        sender = str(msg.getFrom())
        if len(sender.split('/')) > 1:
            sender = sender.split('/')[1]
        if sender.lower().find(self.botname) >= 0:
            return

        self.react(msg.getBody())

# In der folgenden Methode wird für jedes Keyword, dass wir gespeichert haben
# geschaut, ob dieses in der empfangenen Nachricht gefunden werden kann. Falls
# ja, antwortet der Bot mit einer zufällig ausgewählten Antwort aus der Menge
# aller passenden Antworten.
    def react(self, msg):
        time.sleep(self.delay)
        for pattern in self.reactions.keys():
            print "trying to find %s in %s" % (pattern, msg)
            if pattern.search(msg):
                self.say(self.reactions[pattern]
                        [randint(0,len(self.reactions[pattern])-1)])
                return

# Die folgende Endlosschleife wird aufgerufen, wenn der Bot im Chat bleiben und
# auf ankommende Nachrichten warten soll.
    def processing(self):
        while True:
            self.client.Process(1)

# Wenn der Bot gestartet wird, beginnt er mit dem Warten auf Nachrichten. Falls
# er bei der Initialisierung eine Liste von Zitaten übergeben bekommen hat,
# zitiert er aus dieser Liste in zufälligen Abständen zufällige Zitate.
    def run(self):
        processor = Thread()
        processor.run = self.processing
        processor.start()
        if self.minwait==-1 or self.maxwait==-1:
            return
        while True:
            r = randint(self.minwait, self.maxwait)
            time.sleep(r)
            self.say(self.quotes[randint(0,len(self.quotes)-1)])

Das mucbot-Projekt ist frei auf github verfügbar. Es steht unter einer GNU General Public License. Eigentlich bin ich eher ein Fan von BSD und ähnlichen Lizenzen, aber die Verwendung von xmpppy macht dies notwendig.

Vielleicht kann ja der eine oder andere Teile des Mucbots verwenden oder findet hier Anregungen für neue Projekte. Ich grüße mit diesem meinem ersten Blogeintrag alle Leser von IOException.de und freue mich schon darauf bald weitere spannende Dinge mit der Welt zu teilen.

GoogleMap Vaadin Widget (Google Maps JavaScript API V3)

Tobias Schlecht — Fri, 08 Oct 2010 14:59:04 +0000

Wer gerade dabei ist, eine Anwendung mit dem Web Application Framework Vaadin zu realisieren und darüber hinaus beabsichtigt, Google Maps in sein User Interface zu integrieren, hat mehrere Möglichkeiten.

Am naheliegendsten ist es zweifellos, einfach das fertige Vaadin Add-on GoogleMapWidget von Henri Muurimaa dafür zu nutzen, welches die Google Maps JavaScript API V2 einsetzt. Wenn man nun allerdings nicht nur die grundlegenden Funktionalitäten benötigt, kommt die Frage auf, ob man Anpassungen an diesem Widget vornehmen oder ein komplett neues Widget implementieren will.

Für den Fall, dass man sich dazu entschieden hat, ein eigenes Widget zu entwickeln, wäre es natürlich unsinnig, dafür noch die alte API Version und nicht die aktuelle Version, nämlich die Google Maps JavaScript API V3, zu verwenden.

Projektstruktur des Beispielprojekts IOException

Die meisten Entwickler möchten an dieser Stelle jedoch vermutlich kein JavaScript benutzen, da es ja einer der großen Vorteile von Vaadin ist, dass man die gesamte Anwendung in Java implementieren kann.

Also begibt man sich auf die Suche nach einer passenden GWT Library, welche Java Wrapper für die JavaScript API bereitstellt. Auf einer der offiziellen Seiten über die GWT APIs wird man dann aber schnell durch folgende Aussage enttäuscht: “At the present time, the gwt-maps API only supports Google Maps API version 2.”

Jetzt hat man zwei Möglichkeiten: Entweder man wartet bis Google offiziell eine Library für die Version 3 zur Verfügung stellt, wozu es allerdings keine genauen Angaben gibt, wann das geschehen soll, oder aber man verwendet einfach die Alpha-Version der besagten GWT Library, die auf einer inoffiziellen Seite von Google zu finden ist.

Wer genug Zeit zum Warten und sich aus diesem Grund für die erste Möglichkeit ent- schlossen hat, braucht nun eigentlich nicht mehr weiterzulesen ;-) Allen Anderen soll nachstehend am Beispielprojekt IOException gezeigt werden, wie man das Grundgerüst für sein eigenes GoogleMap Vaadin Widget mit Hilfe der GWT Library gwt-google-maps-v3 (Alpha-Version) erstellt.

Anmerkung: Im Folgenden werden lediglich die essenziellen Schritte aufgeführt. Für die Grundlagen zur Erstellung eines Vaadin Projekts wird auf das Book of Vaadin verwiesen, das vor allem für Anfänger sehr empfehlenswert ist.

Zuerst erzeugt man ein gewöhnliches Vaadin Projekt und legt daraufhin die im Screenshot dargestellte Projektstruktur an. Die JAR-Datei gwt-maps3-0.2b.jar (GWT Library) kann in der Rubrik Downloads der bereits erwähnten inoffiziellen Seite von Google heruntergeladen werden.

MANIFEST.MF


Manifest-Version: 1.0
Vaadin-Widgetsets: de.ioexception.widgets.MainWidgetset.gwt.xml

In der Manifest-Datei muss durch das Attribut Vaadin-Widgetsets angegeben werden, wo sich der oberste GWT Modul Descriptor befindet, welcher das zentrale Widget Set definiert und auch als Einstiegspunkt zum Kompilieren dient.

web.xml (Ausschnitt)



    widgetset
    de.ioexception.widgets.MainWidgetset

Dies muss zusätzlich im Deployment Descriptor als innerhalb der -Tags aufgeführt werden.

MainWidgetset.gwt.xml (Ausschnitt)

Wie bereits erwähnt, wird in der Datei MainWidgetset.gwt.xml das zentrale Widget Set definiert. Dazu wird erst einmal vom Default Widget Set und anschließend von den GWT Modul Descriptoren der einzelnen Widget Sets geerbt. Da
das gezeigte Beispielprojekt jedoch nur das GoogleMap Widget beinhaltet, ist dies hier auch die einzige Angabe.

GoogleMapWidgetset.gwt.xml (Ausschnitt)