Benjamins Blog

Auf dem gestrigen Webmontag in Ulm habe ich Node.js vorgestellt, ein Framework für serverseitiges JavaScript für skalierbare Netzwerkanwendungen. Dabei hat es sich um eine eher kurze und oberflächliche Präesentation gehandelt, die die Grundidee des asynchroner I/O Operationen betonen sollte. Detailliertere Beiträge zu Node.js wird es aber in Kürze auf IOException.de geben.

Caches dienen in der Informatik als Methode, Zugriffe auf bestimmte Daten zu beschleunigen, in dem diese vorgelagert/gepuffert werden. Sie sind in verschiedensten Bereichen zu finden, unter anderem auf Prozessoren, in Festplatten, aber auch in Technologien wie dem Web. Verschiedene Verdrängungsstrategien ermöglichen es, die beschränkte Kapazität eines Caches zu berücksichtigen, so dass nur wichtige Werte im Cache gelagert werden. Least Recently Used (LRU), ist eine solche Strategie, die häufig angewandt wird. Sie sortiert die Werte im Cache nach der letzten Nutzung. Wird auf ein Element über einen längeren Zeitraum nicht mehr zugegriffen, so wird es aus dem Cache verdrängt.

In Java lässt sich ein solcher LRU-Cache besonders einfach implementieren, da die Klasse java.util.LinkedHashMap bereits die wesentlichen Mechanismen unterstützt. Eine HashMap ist eine Hash-Tabelle, die Zugriffe auf Werte über ihre Schlüssel regelt. Zusätzlich verkettet die LinkedHashMap aber die Werte noch in einer Liste, womit auch eine Traversierung in Einfügereihenfolge ermöglicht wird. Mithilfe eines Flags in einem der Konstruktoren kann dieses Verhalten geändert werden, so dass bei jedem Zugriff das angesprochene Element neu in diese Liste eingereiht wird. Damit verwaltet die Liste die Zugriffe und ist Basis für die LRU-Strategie.

Die Methode removeEldestEntry() der LinkedHashMap wird bei jedem Schreibezugriff auf die Map, also nach Einfügeoperationen über put() oder putAll() automatisch aufgerufen und bietet die Möglichkeit, durch Überschreiben der Methode die Verdrängungsstrategie zu implementieren. Diese Methode gibt ein boolean zurück, ob der älteste Eintrag gelöscht werden soll. Es ist auch möglich, innerhalb der Methode selbst die Liste zu manipulieren, dann sollte allerdings die Methode immer false zurückgeben. Für den LRU-Cache reicht es aus, die Größe der Map mit dem gewünschten Maximum zu vergleichen. Ist der Inhalt der Map zu groß, so soll das letzte Element gelöscht werden.

Im Folgenden nun der Code dazu. Zu beachten ist noch, dass es sich um eine threadsichere Klasse handelt, da die Map explizit synchronisiert wird.

import java.util.Collections;
import java.util.LinkedHashMap;
import java.util.Map;

/**
 * A thread-safe LRU cache implementation based on internal LinkedHashMap.
 * 
 * @author Benjamin Erb
 *
 * @param <K> Entry Key Type
 * @param <V> Entry Value Type
 */
public class LRUCache<K, V>
{
	public static final int DEFAULT_MAX_SIZE = 1000;

	private final Map<K, V> internalMap;

	public LRUCache()
	{
		this(DEFAULT_MAX_SIZE);
	}

	public LRUCache(final int maxSize)
	{
		this.internalMap = (Map<K, V>) Collections.synchronizedMap(new LinkedHashMap<K, V>(maxSize + 1, .75F, true)
		{
			private static final long serialVersionUID = 5369285290965670135L;

			@Override
			protected boolean removeEldestEntry(Map.Entry<K, V> eldest)
			{
				return size() > maxSize;
			}
		});
	}

	public V put(K key, V value)
	{
		return internalMap.put(key, value);
	}

	public V get(K key)
	{
		return internalMap.get(key);
	}

}

Diesen Beitrag auf IOException.de lesen.

Die Jungs von sneakerblog.net sneakerized.com feiern ihr dreijähriges Bestehen. Grund zu gratulieren, schließlich handelt es sich um einen der bekanntesten deutschen Blog rund um das Thema Sneaker. Alles Gute & Viel Erfolg weiterhin!

Nike Air Force 1 Low '07 (white / white / varsity red)





Vollständigen Artikel lesen...

Ich denke nicht, dass es übertrieben ist zu sagen, dieses Seminar gehört mit zu den Höhepunkten meines bisherigen Studiums an der Uni Ulm. Ein einfaches Seminar haben die Jungs vom Institut für Medieninformatik zu einer vollständig konferenzähnlichen Veranstaltung aufgebohrt – und es hat sich für alle gelohnt. Die Seminarthemen orientierten sich an aktuellen Forschungstrends aus dem Bereich der Medieninformatik und insbesondere aus den Bereichen des Ubiquitous Computings. Allerdings waren die Themen allgemein genug, um mehr als nur punktuelle Forschungsergebnisse anderer zu beschreiben. Vielmehr bot jeder einzelne Vortrag einen guten Einblick in den jeweiligen Themenkomplex ohne all zu spezifisch für die anderen Teilnehmer zu werden. Dies sorgte insbesondere für rege Diskussionen am Ende jeden Vortrags. Die vier Sessions teilten sich in die Bereiche Ubiquitous Computing, Devices and Games, Networking Trends sowie Social Computing ein.
Verschiedene Beiträge werden in Kürze auf IOException vorgestellt.

Doch der Ablauf unterschied sich von dem üblichen Abläufen: Ausarbeitung schreiben, Überarbeitung mit einem Betreuer, Powerpoint Folien erstellen und letztendlich die typischen Präsentationen.



Zunächst wurden wir dazu motiviert, unsere Paper auf Englisch zu verfassen. Der Review-Prozess wurde um ein Peer-Reviewing erweitert, bei dem die Teilnehmer Arbeiten anderer mitbegutachteten. Bei den Vorträgen legten die Betreuer Wert auf ansprechende Präsentationen abseits von Powerpoint und Bullet Points.
Dieser Mehraufwand wurde letztendlich mit einem wirklich sehr konferenznahen Blockseminar belohnt. Es gab Badges für alle Teilnehmer, gedruckte(!) 130-seitige Proceedings mit allen Papern und sogar zwei Keynotes Speeches – darunter ein Forscher aus den Niederlanden
Selbst ein Social Event am Ende hat es gegeben, es war echt noch nett im Barfüsser!

Nochmal großes Lob an Boto, Stefan, Flo, Elmar, Basti und Björn für die besondere Betreuung des Seminars!

Und irgendwie hat dieses Seminar Lust auf mehr gemacht – kurze und interessante Vorträge, die einen Blick über den Tellerrand ermöglichen, gerne auch noch interdisziplinärer. Mal sehen, ob wir da noch etwas weiteres auf die Reihe bekommen.

Als Student im Diplomstudiengang Medien-Informatik an der Uni Ulm ist es Bestandteil des Hauptstudiums, ein Anwendungsfach aus den Teilgebieten der Medien-Informatik zu belegen. Hierbei stehen unter anderem Vertiefungsrichtungen wie Computergrafik, Computer Vision, Ubiquitous Computing, Medienpädagogik, Interaktive Systeme, Interaktives Video oder Mensch-Maschine Dialogsysteme zur Auswahl.

Meine Wahl hierbei fiel auf Ubiquitous Computing – dem Trend hin zum allgegenwärtigen Computer oder dem „Internet der Dinge“. Ob als intelligenter Kühlschrank, im vernetzten Auto oder in Form von intelligenten Smartphones, der Computer und mit ihm oft auch das Internet werden immer omnipräsenter. Das Anwendungsfach besteht einerseits aus den Vorlesungen Multimediasysteme und Mobile & Ubiquitous Computing, und andererseits aus einer wissenschaftlichen Projektarbeit über zwei Semester in Kleingruppen.

Derzeit arbeiten Stefan, Cookie und ich an einer Idee von Stefan, aus der nun unser Projekt entsprungen ist: Einerseits erlaubt der technologische Fortschritt performante mobile Internetzugänge und eine fast ubiquitäre Vernetzung. Auf der anderen Seite ist qualitatives und verteiltes Dokumentieren von Ereignissen unter echtzeitnahen Bedingungen bisher nicht ohne weiteres möglich. Genau hier setzt unser Projekt, diretto (ital.: direkt, aus erster Hand) an.



Zunächst versuchen wir im Rahmen des Projekts die Vorgänge und Merkmale verteilter Berichterstattung auf eine allgemeine und offene Schnittstelle zu abstrahieren. Anschließend werden wir Referenzimplementierungen verschiedener Dienste bereitstellen, die darauf aufbauen. Das beinhaltet sehr unterschiedliche Teilaspekte, wie die Aufnahme und Erstellung von Beiträgen in verschiedenen Formen wie Bild, Text, Audio oder Video, aber auch die Verteilung, Speicherung und Aufarbeitung solcher Daten zu nützlichen Informationen.

Unser geplantes System ist an keinen festen Anwendungszweck gebunden und soll in verschiedensten Szenarien eingesetzt werden können. Ein möglicher Bereich ist der Katastrophenschutz. Hier ist es besonders wichtig, bei großflächigen Einsätzen nach Unfällen oder Naturkatastrophen zunächst Ordnung ins Chaos zu bringen. Das bedeutet vor allem Sammeln, Filtern und Bewerten eintreffender Daten und das Erstellen von Bestandsaufnahmen. Eine verteilte, mobile Anwendung hierfür ist genauso interessant wie die Möglichkeit, einen Teil der Aufgaben wie das Bewerten auch entfernt durchführen zu können. Ein anderes Szenario wäre ein Live-Bericht eines öffentlichen Großereignisses. So könnte mithilfe eines solchen Systems zum Beispiel ein Fahrradrennen übertragen werden, in dem die Beiträge verschiedener Zuschauer an verschiedenen Stellen der Strecke digital und echtzeitnah gesammelt werden und über das Internet Interessierten zugreifbar gemacht werden. Ein weiteres mögliches Einsatzszenario ist die Dokumentation von Veranstaltungen wie Demonstrationen. Nicht zuletzt die Ereignisse der Freiheit-statt-Angst Demonstration in Berlin haben gezeigt, wie wichtig eine entsprechende Dokumentation sein kann.

Während sich Stefan sich zunächst seiner ursprünglichen Idee widmen wird, mithilfe eines mobilen Computers im Rucksack Fotojournalismus auch unter widrigen Umständen durchführen zu können, wird sich Cookie anfangs um die Integration eines Smartphones kümmern. Ich werde mich hauptsächlich mit den technischen Aspekten der API und vor allem der serverseitigen Speicherung der Daten beschäftigen, was ich mir aufgrund meines Interesses an verteilten Systemen entsprechend ausgesucht habe. Da die genannten Szenarien Anforderungen an das System in Bezug auf Phasen hoher Nutzungsintensität und Verfügbarkeit stellt, muss ein solches System vor allem gut skalieren und ausfallsicher designt sein. Dann wird es für uns als nächstes darum gehen, weitere Aspekte zu implementieren und vor allem das System unter echten Bedingungen zu testen.

Aktuelle Informationen zum Projekt und dessen Verlauf gibt es übrigens auf unserer Projektseite unter diretto.org.

An meiner Uni sind einige Webressourcen nur aus dem Intranet zugreifbar, das heißt man braucht als Client eine IP aus dem Uni-Netz. Um von extern darauf zuzugreifen, ist die Einwahl über ein VPN notwendig. Neben der klassischen "schwergewichtigen" Einwahl über einen VPN-Client gibt es noch die Möglichkeit, einen Web-VPN zu nutzen. Hier werden nach der Authentifizierung alle HTTP-Anfragen über eine spezielle Seite der Rechenzentrums getunnelt. Leider lässt nicht nur die Verfügbarkeit des Dienstes manchmal zu wünschen übrig, sondern auch die verfügbaren Bandbreiten machen es uninteressant für den Download größerer Paper.

Als Alternative hierzu ist mir die Möglichkeit begegnet, mithilfe des Application Level Port Forwardings von SSH Zugriffe zu tunneln. Durch den Flag "-D portnummer" erzeugt der SSH-Client beim Verbinden einen lokalen SOCKS-Proxy auf diesem Port, der über den SSH-Tunnel Requests weiterleitet. Endpunkt stellt der SSH-Server da. Mithilfe zusätzlicher Flags lässt sich außerdem ein Timeout unterdrücken.

Im Falle der Uni Ulm und einer Einwahl auf den Server des Rechenzentrums (KIZ) sieht der Aufruf so aus:

ssh -D 8800 -o ServerAliveInterval=60 s_login@login.rz.uni-ulm.de

Nach erfolgreichem Verbindungsaufbau steht dann lokal unter dem Port 8800 der SOCKS-Proxy zur Verfügung und kann im Browser eingetragen werden. Für eine dynamische Nutzung bieten sich unter Firefox Plugins wie FoxyProxy an. Hier lassen sich Regelsätze definieren, wann dieser Proxy benutzt werden soll, zum Beispiel für alle Uni-Seiten.

Anders als manch andere imperative Programmiersprachen, unterstützt Java nur die Rückgabe eines Wertes bei einem Methodenaufruf. Jedoch ist es häufig interessant, mehrere Werte zurückzugeben. Grundsätzlich lassen sich hier zwei Szenarien unterscheiden. Bei der Rückgabe von mehreren gleichartigen Typen wird meist eine Klasse des Collections-Frameworks verwendet, wie zum Beispiel List oder ein Array. Manchmal will man aber auch völlig verschiedene Typen gemeinsam zurückgeben. Gängige Praxis ist es hier, ein Object-Array zurückzugeben und dann quasi beim Implementieren festzulegen, von welchem Typ die einzelnen Werte sind und entsprechen zurückzucasten. Dies ist leider weder typsicher, noch lässt sich die vorherige Festlegung im Code erzwingen. Abhilfe schafft hier eine generische Holder-Klasse, die einzelnen Werte typsicher kapselt und als einziger Rückgabewert verwendet werden kann.

Hier ein Beispiel für die Rückgabe über ein Object-Array:

private Object[] doItUnchecked()
{
	String s = "foo";
	Date d = new Date();

	return new Object[] { s, d };
}

Aufruf:

// unchecked variant: dangerous!
Object[] returnValues = t.doItUnchecked();
String s = (String) returnValues[0];
Date d = (Date) returnValues[1];

Eine generische Holderklasse (hier: immutable):

/**
 * Immutable holder type for two values.
 * 
 * @author Benjamin Erb
 *
 * @param <F> type of first value
 * @param <S> type of second value
 */
public class PairHolder<F, S>
{
	private final F first;
	private final S second;
	
	public PairHolder(F first, S second)
	{
		this.first = first;
		this.second = second;
	}
	
	public F getFirst()
	{
		return first;
	}
	
	public S getSecond()
	{
		return second;
	}
}

Verwendung in Methode:

private PairHolder<String, Date> doItChecked()
{
	String s = "foo";
	Date d = new Date();

	return new PairHolder<String, Date>(s, d);
}

Aufruf:

// check variant: safe already at compile-time
PairHolder<String, Date> h = t.doItChecked();
String s = h.getFirst();
Date d = h.getSecond();

Die Holderklasse lässt sich auch noch beliebig erweitern, um Tripel, Quadrupel etc. zu halten. Wer für 2-Tupel keine eigene Klasse implementieren möchte, kann übrigens auf AbstractMap.SimpleEntry<K,V> oder AbstractMap.SimpleImmutableEntry<K,V> zurückgreifen.

Nike WMNS Air Max 1 (white / white / purple / pink)






Vollständigen Artikel lesen...