IOException.de

Wer einmal mit einer Versionsverwaltung wie Git oder Subversion gearbeitet hat, möchte es für die eigene Arbeit nicht mehr missen: Nie mehr verzweifeln, weil der Texteditor nur die letzten X Änderungen über die allseits beliebte Tastenkombination Strg+Z zurücknehmen lässt. Kein leidiges Abgleichen von Dateien per Hand, wenn mehrere Leute am gleichen Projekt arbeiten.
Für die meisten dieser Versionskontrollsysteme ist ein zentraler Server, auf dem die Datenstände und Versionen allen Projektmitgliedern bereitgestellt werden können, zwingend erforderlich oder zumindest sehr empfehlenswert. In der Open-Source-Welt hat sich hierfür GitHub etabliert, was das kostenfreie Git-Hosting für öffentliche Projekte erlaubt. Wer – wie wir für unser Softwareprojekt (Sopra) im Rahmen des Informatikstudiums – im Team an einem privaten Repository arbeiten möchte, muss bei GitHub schon etwas Geld in die Hand nehmen: Zwar wäre es uns die sieben Dollar im Monat wert gewesen, da ich aber die Vorteile von Git auch für ein paar andere eigene (nicht öffentliche) Projekte verwenden wollte und einen vServer quasi brachliegen hatte, sah ich mich nach selbstgehosteten Alternativen um – und stieß auf Gitlab.

Gleich vorweg: Wenn man Git alleine nutzt, braucht man natürlich überhaupt keinen Server. Und wem grafische Oberfläche ohnehin ein Fremdwort ist, der kann seinen Server sicher auch nur als reinen Git-Server betreiben. Für unser Team waren in der Programmentwicklung jedoch die Features, die auch GitHub bietet, sehr wichtig: Wir wollten Issues online erfassen, Commits direkt im Code kommentieren. Ja, vielleicht sogar MergeRequests direkt über die Web-Oberfläche abarbeiten. All dies wurde durch Gitlab ermöglicht, wenn auch zum Teil erst nach ein paar Versionssprüngen.

Installation und Updates

Versionssprünge? – Ja, Gitlab steckt so gesehen noch in den Kinderschuhen. Oder anders formuliert: Es wird stetig verbessert. Wer sich ein wenig mit Ruby auskennt oder einfach ein paar neue Ideen einbringen will, kann ja mal bei Gitlab auf GitHub vorbeischauen.
Wir fingen im März unter Nutzung der Version 2.2 an, mit Gitlab zu arbeiten. Mittlerweile läuft auf meinem Server die 2.6er-Version, in den kommenden Tagen müsste das Update auf 2.7 veröffentlicht werden. Anfangs weigerte ich mich, das System zu aktualisieren, um das Sopra nicht unnötig zu gefährden. Es zeigte sich jedoch schnell, dass jedes einzelne Update sehr nützliche Features mit sich brachte – so kamen seit Beginn unserer Arbeit die Möglichkeit der Milestones, Taggen von Issues und das Annehmen von MergeRequests über die Web-Oberfläche dazu.

Die Installation auf dem eigenen Server geht relativ einfach von der Hand. Eine Schritt-für-Schritt-Anleitung dazu gibt es im Gitlab-Wiki, die ich eigentlich nur abarbeiten musste. Offiziell unterstützt wird nur Ubuntu, es finden sich im Internet aber mittlerweile genügend Hilfen, wie man Gitlab auch auf CentOS- oder anderen Servern zum Laufen bekommt. Einmal installiert gehen Updates so einfach wie nur möglich von der Hand: Ein einfaches git pull und rake db:migrate reichen in aller Regel aus, um das System auf den neuesten Stand zu bringen.

Features

Wie oben schon geschrieben: Im Prinzip bringt Gitlab alles mit, was man auch von GitHub kennt. Das große Vorbild schwingt in allen Diskussionen um neue Features mit. So birgt die Oberfläche von Gitlab erstmal auch kaum Überraschungen.
Da ich noch nie auf GitHub in einem Team gearbeitet habe, kann ich das leider nicht vergleichen. In Gitlab gibt es eine ganze Reihe an verschiedenen Rollen, vom “Guest” bis “Master”. Die Rollenverteilung auch im Team umzusetzen, erwies sich bereits nach wenigen Tagen gemeinsamer Arbeit am Sopra als sehr nützlich: Durch die Unterscheidung zwischen “Developer” und “Master” konnten nur noch zwei Mitglieder in unseren Master-Branch pushen und waren dementsprechend für das Mergen und Schließen der Issues hauptverantwortlich.

Letztlich nutzten wir im Team mit Ausnahme der sogenannten “Wall” alle Mittel, die uns Gitlab an die Hand gab. Am anschaulichsten wird das vielleicht, wenn man betrachtet, wie sich unser Workflow seit Benutzung von Gitlab geändert hat:

• Gerade am Anfang war die intensive Arbeit mit Git für uns alle noch ziemlich neu. Das Wiki eignet sich sehr gut, um auch gemeinsam die wichtigsten Kommandos zusammenzufassen. Aber etwa auch um nochmal die Programmierkonventionen zu benennen.
• Code wird nicht mehr per Skype oder Google Hangout unter Nutzung der Bildschirmübertragung diskutiert, sondern einfach über die Weboberfläche – und zwar gerne auch direkt mit Kommentaren im Code oder Commit.
• Issues und Arbeitsaufträge werden nicht mehr über Rundmails verteilt, sondern einfach als neue Einträge unter Issues hinterlegt.
• “Bei mir trat gerade ein Fehler in Deinem Modul auf.” – “Schick mir mal die Fehlermeldung per Skype”. Solche Dialoge gibt es nicht mehr. Wir nutzten Skype zwar natürlich weiter intensiv zur Teamdiskussion, lange Fehlermeldungen haben im Chat aber nichts zu suchen. Und wanderten somit in die Snippets, wo man ihnen eine Expire-Zeit zuweisen kann.
• Jegliche Dokumente wie die Benutzerdokumentation werden auch im Gitlab hinterlegt. Und nicht wie zuvor über Dropbox verteilt.
• Unverändert blieb jedoch die Nutzung von GoogleDocs. Für Dokumente, die sich häufig verändern, wie etwa das Projekttagebuch, ist das doch noch einfacher, da Gitlab im Gegensatz zu GitHub (noch?) nicht das Ändern von Dateien via Browser unterstützt.

Grundsätzlich gab es also nichts, was uns noch gefehlt hätte. Nervig waren hin und wieder lediglich die kleinen Aussetzer, auf die ich im nächsten Abschnitt mal kurz eingehen werde.

Limits

Auch wenn sich Gitlab und GitHub nicht nur optisch sehr ähneln, verfolgen beide Systeme eigentlich unterschiedliche Ziele: Gitlab beschränkt sich komplett auf das Hosting von privaten Repositories. Es ist also nicht möglich, Gitlab als selbst gehosteten Ersatz für Github zu nutzen, und seine Open-Source-Projekte damit zu verwalten. Klar, prinzipiell geht das natürlich auch, aber dann kann eben niemand den Code sehen. Im Gegensatz zu GitHub bietet der Klon nämlich keine Möglichkeit, auf Projekte ohne Registrierung zuzugreifen. Und neue Benutzer anlegen kann nur der Admin. Auch wenn in sehr regelmäßigen Abständen von etwa 2 Wochen ein neuer Issue an die Entwickler gerichtet wird, dies doch umzustellen, bleiben diese ihrer Linie treu und grenzen sich damit ganz klar von Github ab. Und das auch ganz explizit mit der Aussage, dass Open-Source-Projekte eben am besten zentral auf GitHub gehostet werden.

Das Bearbeiten von MergeRequests direkt über die Weboberfläche ist zwar sehr komfortabel, sollte naturgemäß aber nur bei einfachen Änderungen benutzt werden. Ohnehin prüft Gitlab, bevor es die Möglichkeit anbietet, ob es zu irgendwelchen Merge-Konflikten kommt. Doch auch wenn dem nicht so ist, habe ich Abstand davon genommen, umfangreiche Änderungen über diesen Weg zu übernehmen. Letztlich schien mir der traditionelle Weg über git merge und ggf. git mergetool doch immer noch am sichersten.

Etwas Schluckauf kann man Gitlab im Moment auch noch durch den intensiven Gebrauch von Umlauten bereiten: Commit-Messages, die Umlaute beinhalten, können mitunter dafür sorgen, dass ein ganzer Dateibaum in der Weboberfläche nicht mehr verfügbar ist. Umlaute in Dateinamen sorgen dafür, dass die ansonsten sehr hilfreiche Funktion, um ein komplettes Repository als *.tar.gz herunterzuladen, plötzlich nicht mehr funktioniert. Schade ist, dass das System in diesen Fällen keine ordentliche Fehlerseite liefert, sondern schlicht mit 404 quittiert. Und man dann händisch versuchen muss, die Sachen in der Datenbank zu korrigieren.
Generell hat die Zahl der Fehler mit jedem Update aber gut abgenommen, sodass man sich einfach auf die Vermeidung von Umlauten einlassen sollte und ein sehr gutes und stabiles System bekommt.

Screenshots

Eine Demo gibt es ebenfalls auf den Seiten von Gitlab.

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.

Im Rahmen der Vorlesung “Mobile & Ubiquitous Computing” (bin derzeit mitbetreuender Hiwi) waren wir auf der Suche nach passenden Übungsaufgaben. Eine Übung davon sollte verschiedene Aspekte aktueller Mobilapplikationen (Sensorkontext, Web Services, Live Notifications) einbeziehen, ohne dabei allzu komplex zu werden.

Als ansatzweise reales Szenario hierfür dient die Mensa. Zu Stoßzeiten ist es häufig schwierig, in einer größeren Gruppe gemeinsam zu essen. Spätestens an den Kassen teilt sich die Gruppe auf und es ist schwierig, die Anderen zu finden. Ein Teil sitzt vielleicht auch schon an irgendeinem Tisch, während andere immer noch an der Essensausgabe warten. Was man also unbedingt braucht, ist ein Mensafinder. Der Mensafinder ermöglicht es, anderen seine grobe Position in der Mensa mitzuteilen oder aufzuzeigen, wo andere Leute sitzen. Aufgrund der Einschränkungen vor Ort (kein GPS-Empfang, WLan-Ortung zu ungenau) haben wir uns auf eine einzige Kontextinformationen beschränkt, die bereits eine ausreichende Lösung bietet – die Kompassausrichtung. Anstatt die genaue Position zu ermitteln, verwenden wir eine grobe Richtung abhängig von einem Fixpunkt im Zentrum des Raums (Wendeltreppe). Bereits sitzende Personen richten ihr Mobilgerät in Richtung des Fixpunktes aus, suchende Personen können ausgehend vom Fixpunkt den Richtungen folgen.

Technisch besteht der Mensafinder aus einem Webservice und mobilen Anwendungen. Der Webservice basiert auf REST und bietet als besonderes Feature das ‘Streamen’ neuer Events (neue/aktualisierte Peilungen oder Abmeldungen). Hierfür wird durch den Client eine HTTP-Verbindung geöffnet und serverseitig nicht direkt geschlossen. Stattdessen werden neue Events via Chunked Encoding in die offene Verbindung geschrieben, ähnlich wie bei Streaming API von Twitter. Der Service wurde mit node.js implementiert, Quellcode sowie Dokumentation der REST API sind auf github verfügbar.

Da es sich nur um eine Demo-Applikation handelt, fehlen einige wichtige Features. Es gibt keine Authentisierung der Benutzer und es werden alle Peilungen aller Benutzer übertragen (es gibt keine Kontaktlisten). Interessant wäre natürlich die Anbindung an bestehende Dienste, die bereits eine Authentisierung und Kontaktlisten bereitstellen, so wie beispielsweise Facebook Connect.

Am Mittwoch, den 16. Februar, stellen Studierende des Studiengangs Medieninformatik die Highlights ihrer Anwendungsfächer um 16 Uhr im H20 vor. Erfreulicherweise sind mit MAMPF und diretto auch zwei Projekte von uns mit dabei.

Projekte:

• Interaktive Musikbibliothek (Interaktive Systeme)
• Interaktives Skript MMS (Interaktive Systeme)
• Campus Radio (Medienpädagogik)
• MAMPF (Ubiquitous Computing)
• diretto (Ubiquitous Computing/Interaktive Systeme)
• Parkhaus (Interaktives Video)
• Biologische Barcodes in Gesichtern (Computer Vision)
• Mehrbildanalyse zur Bestimmung von Kopfposen (Computer Vision)
• Realtime Rendering (Computer Graphics)

Weitere Informationen gibt es unter: http://www.uni-ulm.de/in/mi/highlights.html

MAMPF [Fabian Groh, Oliver Stamm, Steffen Scherle, Sven Reichel, Timo Müller]

diretto ))) [Benjamin Erb, Christian Koch, Stefan Kaufmann]

Die Küche ist wohl weiterhin einer der traditionsreichsten Plätze in der modernen Gesellschaft. Auch wenn es Feministinnen nicht gefallen wird, so steht „Oma“ für ein Qualitätsmerkmal im Bereich der zünftigen Küche. Handschriftliche Rezeptsammlungen sind auch heute noch in modernen Küchen zu finden. Dabei handelt es sich nicht selten um über Generationen gesammelte Werke. Als Kind lernt man meist schon durch Selbstversuch, dass der Topf über eine Herdplatte erwärmt wird und lernt so recht schnell wie unsere Gesellschaft zu warmen Speisen gelangt.

Mit unserem Projekt wollen wir das Kochen nicht neu erfinden. Vielmehr handelt es sich bei der Multifunctional and Adaptive Meal Preparation Facility (MAMPF) um ein Konzept, welches zeigen soll, dass ubiquitäre Unterstützung auch im Bereich der Küche sinnvoll einzubringen ist. Dafür möchten wir einige der festgefahrenen Methoden aufbrechen und uns überlegen, wie diese sinnvoll zu verändern bzw. zu erweitern sind. Oft beschränkt sich ein Haushalt auf eine gut abzählbare Menge von immer wiederkehrenden Gerichten. Dies hat zum Einen den Grund, dass diese Gerichte Lieblingsspeisen sind, zum Anderen liegt dies an Zeit- und Motivationsmängel, sich die Zubereitung eines neuen Gerichtes anzueignen.
Durch ein System, welches Rezepte bereitstellt und Unterstützung für den Kochvorgang anbietet, kann möglicherweise diese Hürde etwas herabgesetzt werden. Durch maschinenlesbare Rezepte lassen sich auch sehr einfach Inhaltsstoffe überprüfen, beispielsweise zur Vermeidung von Unverträglichkeiten beziehungsweise Allergien oder für eine gesündere Ernährung.

Ein solches Format bringt neben der Möglichkeit zur Kochunterstützung eine Fülle weiterer Eigenschaften. So können Rezepte sehr gut kategorisiert, durchsucht, getauscht, bewertet oder modifiziert werden. Damit wäre es auch möglich Rezepte über eine Online-Plattform für andere zugänglich zu machen. Die klassische Bedienung soll so verändert werden, dass eine einfachere Handhabung möglich ist. Ein Kochvorgang zum Aufkochen von Wasser beginnt meistens, indem man einen Topf mit Wasser füllt, sich eine geeignete Platte auf dem Herd aussucht und anschließend das Bedienelement für diese Platte auf die höchste Stufe stellt.
Bei unserem Konzept soll vor Allem diese letzte Indirektionsstufe wegfallen, indem das System sowohl weiß, wo sich das Kochgeschirr befindet, als auch, wie dieses anzusteuern ist. Dies nennt sich dann ‘zoneless cooking’.

Es handelt sich in diesem Punkt um eine Machbarkeitsstudie, da wir aus Kostengründen keine große Fläche aus vielen kleinen Induktionsspulen zur Verfügung haben. Derartige Produkte werden auch von den großen Firmen erforscht, die leider nicht an einer Beteiligung an diesem Projekt interessiert waren. Daher wird mit drei einfachen Induktionskochplatten das Prinzip der Topferkennung und des gezielten Ansteuerns umgesetzt, welches auf eine großflächige Induktionsmatrix übertragbar ist.

Die MAMPF stellt dann schließlich ein vielseitiges Küchensystem dar, das den Benutzer bei Bedarf in weiten Teilen unterstützt. Dies bedeutet, dass der Benutzer des Systems in keinster Weise in seinen Möglichkeiten eingeschränkt werden soll und auch künftig in gewohnter Weise kochen kann. Die gebotene Unterstützung umfasst mehrere Bereiche wie erhöhte Sicherheit, einen neuen Ansatz der Interaktion sowie Begleitung durch Rezepte.

Die Darstellung des Systemzustandes, sowie aller Anweisungen für ein Rezept, werden auf einem Monitor über der Kochplatte angezeigt. Bedient wird das System über einen in die Kochplatte eingelassenen, berührungsempfindlichen TabletPC. Die Bedienfläche ist somit von der Ausgabe getrennt, kann aber auch die Ausgabe für eine direkte Interaktion darstellen. Hiermit ist es möglich auch von entfernten Geräten auf die Kocheinheit zuzugreifen und Änderungen am System durchzuführen.

Mithilfe einer Datenbank sollen Benutzerinformationen gesammelt werden. Diese Informationen erlauben später eine genauere Berechnung der benötigten Kochdauer oder das sortieren von bestimmten Rezepten.

Um dieses Projekt zu realisieren, wird wie bereits erwähnt auf die Technik der Induktion gesetzt. Die Kochplatten werden durch Hardwarenahe-Programmierung über Mikrocontroller angesprochen. Des Weiteren verwenden wir Algorithmen aus der Computer Vision zur Objekterkennung und -tracking, ein selbst spezifiziertes Rezeptformat und ein hohes Maß an Modularität durch die Common Application Library (CAL) des .NET-Frameworks in Verbindung mit dem Model-View-ViewModel-Pattern. Durch dieses Lose-gekoppelte Framework ist es möglich mit fünf Personen unabhängig von den Arbeitsfortschritten der anderen zu entwickeln.

Die Motivation MAMPF umzusetzen besteht darin das Kochen zu vereinfachen. Ungeübte Köche und komplizierte Rezepte sollen nicht mehr im Widerspruch zueinander stehen.

Im Laufe eines Studiums muss man ja diverse Praktika machen. Eines davon steht dieses Semester nun auch bei mir an. Nachdem ich lange überlegt hab, ob für einen Nebenfach Medizin Informatiker nun OS im Eigenbau, Autonomous Underwater Vehicle oder Humanoid-Roboter am besten sei, entschied ich mich für letzteres.

Hierbei geht es um einen kleinen Graupner Humanoiden der Serie RB-1000. Diesem Humanoiden, getauft auf T-1000 aka Arnie, müssen wir in einem Teamprojekt das Gehen beibringen.

Arnie hat 21 Servos, 2 LED-Augen(rot) und einen Microkontroller, der an der Uni eigenständig entwickelt wurde, versehen mit einer Bluetooth-Schnittstelle und einem Gyroskop. In zwei Praktika zuvor wurden zwei Interfaces entwickelt, das eine in MatLab und das andere in C/C++. Derzeit können wir uns noch nicht ganz entscheiden, welches von beiden wir verwenden werden. Allerdings ist mir das C/C++ gerade noch lieber, da es weniger Probleme bereitet und von uns in – welch Einfalssreichtum – Skynet umbenannt wurde. Das schöne dabei ist, dass man beispielsweise ein Bashscript schreiben kann für die Ansteuerung und dann das ganze einfach an Skynet pipen kann.

Bisher bestand unsere Tätigkeit darin, Arnie erst einmal komplett zu entrümpeln. Wir haben unnötige Meter an Servokabel entfernt, die Stromversorgung neu angeschlossen, neue Schalter angebracht, die Batterie im Brustkorb durch ein passendes Netzteil ersetzt, was uns die Handhabung um mindestens 120% verbessert, die Interfaces gestestet und vorbereitet. Demnächst werden wir auch noch eine kleine Justierungsstation basteln, damit man ihn vor Inbetriebnahme immer optimal einstellen kann.

Natürlich haben wir auch schon ordentlich an ihm getestet was er kann und wie es geht. Hier sieht man ihn, wie er winkt.

This is only the beginning….

Heutige Mobilgeräte wie Smartphones, Netbooks oder PDAs stellen zu einem großen Teil drahtlosen Zugriff auf das Internet bereit. Zugleich bieten diese Geräte häufig auch die Möglichkeit, multimediale Inhalte wie Bilder, Videos oder Tonmitschnitte überall zu produzieren. Alternativ können sie zumindest als Brücke ins Internet fungieren und dedizierte Geräte wie Digitalkameras anbinden.

Trotz dieser theoretischen Möglichkeiten existieren bisher kaum Anwendungen, die mithilfe dieser Technologien eine multimediale Berichterstattung in quasi Echtzeit ermöglichen. Das Ziel des diretto-Projektes ist es, eine solche Plattform zu entwickeln und Beispiellösungen für die Integration mobiler Geräte aufzuzeigen. Zusätzlich zu Sammlung der mutlimedialen Inhalte liegt ein weiter Fokus auf der Analyse, Bewertung und Verbesserung der erhaltenen Daten – sowohl durch das System als auch durch die Benutzer selbst. So kann zum Beispiel die Genauigkeit von Metadaten wie Orts- und Zeitangaben verbessert werden, Beiträge können mithilfe von Tags klassifiziert und verschiedene mutlimediale Inhalte untereinander sinnvoll verlinkt werden. Durch das System erzeugte Gruppierungen unterstützen den Benutzer zusätzlich bei der Auswertung der Inhalte.

Als Grundlage für das komplette Projekte werden zeitgemäße Web-Technologien eingesetzt. Somit ist die Plattform offen, sehr leicht erweiterbar und skaliert auch bei der Nutzung in größeren Szenarien. Die API steht in Form eines REST-konformen Webservices zur Verfügung. Metadaten werden im leichtgewichtigen JSON-Format kodiert. Ein spezieller PubSubHubbub-Endpunkt ermöglicht Benachrichtigungen über neue Inhalte in Echtzeit. Dezentrale Zusatzdientse steuern zusätzliche Funktionalitäten bei.

Eine mächtige Weboberfläche bietet Zugriff auf die Gesamtheit der erhobenen Daten – auch entfernt über das Internet. Sie bietet die Grundlage für komplexe Auswertungen der vorhandenen Multimediadaten und zugehörigen Metadaten. Im Vordergrund steht hierbei auch die Unterstützung des Benutzers beim Umgang mit den vieldimensionalen Daten.

Für die Integration mobiler Systeme werden verschiedene Clients entwickelt und erprobt. Ein Smartphone-Client erlaubt es dem Besitzer eines Smartphones direkt zum Reporter vor Ort zu werden und Inhalte beizusteuern. Für die Anbindung dedizierter Hardware wie einer digitalen Spiegelreflexkamera wird eine besondere Lösung erabreitet. Ein mobiler Rechner im Rucksack soll als Uplink-Gerät dienen und frisch geschossene Bilder ohne Verzögerung direkt auf die Plattform hochladen. Mithilfe einer solchen Lösung können Fotojournalisten als echte Live-Berichterstatter agieren und Pausen für den Upload entfallen.

Eine solche Plattform eignet sich je nach Ausrichtung für eine Vielzahl verschiedener Einsatzszenarien. So könnte es zur Live-Dokumentation großer Ereignisse dienen. In einem geschlossenen Kontext könnte es Einsatzkräfte bei Großschadenslagen dabei helfen, in kürzerer Zeit einen detaillierteren Überblick zu bekommen und unterstützende Kräfte zur Auswertung fernab einbinden.

Das Projekt wurde im Rahmen des Anwendungsfaches Ubiquitous Computing an der Universität Ulm von einem studentischen Team entworfen und nun in Zusammenarbeit mit einem Team für Interaktive Systeme als Prototyp realisiert. Nähere Informationen gibt es auf der Projektseite www.diretto.org

Als Student im Diplomstudiengang Medieninformatik 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.

Ubiquitous Computing steht für den 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 allgegenwärtiger und verschmelzen mit der Umgebung. Das Anwendungsfach besteht einerseits aus den Vorlesungen Multimediasysteme und Mobile & Ubiquitous Computing, und andererseits aus einer wissenschaftlichen Projektarbeit über zwei Semester in Gruppen.

Verschiedene Autoren des Blogs arbeiten derzeit gemeinsam an solchen Projekten und werden diese hier genauer vorstellen.

Am Mittwoch, den 10. Februar, stellen Studierende des Studiengangs Medieninformatik die Highlights ihrer Anwendungsfächer um 16 Uhr im H20 vor.

Vorgestellte Projekte:

• Echtzeitgrafik (Praktikum Computergrafik)
• Visuelle Wahrnehmung (Praktikum Computer Vision)
• awarenia, iNet, w3i (Anwendungsfach Interaktive Systeme)
• pocketU (Anwendungsfach Medienpädagogik)
• newsmachine (Anwendungsfach Interaktives Video)
• TTable (Anwendungsfach Ubiquitous Computing)
• Anwendungsfach Dialogsysteme

Weitere Informationen gibt es unter: http://www.uni-ulm.de/in/mi/streiflicht.html

Von uns ist dieses Mal noch niemand dabei, allerdings werden wir in Kürze über unsere eigenen Anwendungsfachprojekte berichten, an denen wir derzeit arbeiten.