Projektbericht. Ruben Schempp Maps on Rails

Transkript

1 Projektbericht Ruben Schempp Maps on Rails Fakultät Technik und Informatik Department Informatik Faculty of Engineering and Computer Science Department of Computer Science

2 I Ruben Schempp Maps on Rails Ausarbeitung eingereicht im Rahmen der Veranstaltung Projekt im Wintersemester 2007/2008 im Studiengang Master of Science Informatik am Department Informatik der Fakultät Technik und Informatik der Hochschule für Angewandte Wissenschaften Hamburg Betreuender Prüfer: Prof. Dr. Kai von Luck Abgegeben am 28. Februar 2008

3 Inhaltsverzeichnis II Inhaltsverzeichnis 1 Einführung Arbeitsumgebung Vision Szenario Ziele Vorgehensweise Evaluierung Kartendienst Ruby on Rails Google Maps on Rails Yellow Maps for Ruby JavaScript Google vs. Yahoo! Maps Aktualisierungsstrategie Yahoo! Maps on Rails Rails Helper Web-Browser Wirtschaftskontakte Geoinformationsysteme der Stadt Hamburg UbiLabs Zusammenfassung Fazit Ausblick Literaturverzeichnis 17

4 Abbildungsverzeichnis III Abbildungsverzeichnis 3.1 (Google) Maps on Rails (Yahoo!) Maps on Rails OpenLayers

5 1 Einführung 1 1 Einführung In diesem Bericht werden die Erfahrungen und Ergebnisse des Projekts vorgestellt. Das Projekt schließt an die Vorarbeiten des vergangenen Semesters in Anwendungen I [Schempp, 2007] an. Es wurde parallel zu den Arbeiten Anwendungen II [Schempp, 2008a] und Seminar [Schempp, 2008b] durchgeführt. In den drei erwähnten Arbeiten werden die Vorbereitungen auf die Masterarbeit beschrieben. Es wird eine Anwendung namens Maps on Rails an Hand eines Szenarios (Einsatzleitstelle) beschrieben. Ziel der Projektarbeit war ein erstes praktisches Herangehen an die Aufgabenstellung zu ermöglichen, um so zu sehen, welche Möglichkeiten und vor allem welche Probleme bei der Umsetzung der Anwendung auftreten. Für Maps on Rails war zu allererst zu prüfen, ob sich die Anforderungen des Szenarios auch tatsächlich mit der favorisierten Technik umsetzen lassen. 1.1 Arbeitsumgebung Die Programmierung der prototypischen Versuche und Anwendung erfolgte in Ruby mit dem Framework Ruby on Rails. Wo nötig, wurden auch HTML, CSS und JavaScript eingesetzt. Als Datenbank kam SQLite (mit einem Plugin für Rails) zum Einsatz. Der in Rails integrierte Webrick-Server wurde ebenfalls verwendet. Auf dem Client kam i.d.r. der Firefox Browser zum Einsatz. Die Programmierung erfolgte unter MacOS 10.5 mit dem Editor TextWrangler. Die Verwendung von Locomotive als Rails-Werkzeug für MacOS ist nicht unbedingt empfehlenswert, solange es mit der bereits in MacOS installierten Ruby-Version und mit dem Umgang auf der Kommandozeile keine Probleme gibt. Als Verbesserung kann die Entwicklungsumgebung Eclipse oder auch Aptana Studio eingesetzt werden. Aptana Studio 1 ist eine von Eclipse abstammende, aber speziell auf Web- Entwicklung spezialisierte IDE, die eine Ruby on Rails Unterstützung bietet. Eine kostenpflichtige Alternative stellt auch die Entwicklungsumgebung IntelliJ IDEA 2 dar. 1 Siehe: 2 Siehe:

6 2 Vision 2 2 Vision Die Vision des Projekts besteht in einer ersten prototypischen Umsetzung des Szenarios. Letztlich soll die Anwendung Maps on Rails auf einem Großbildschirm eines Leitstands einsetzbar sein. Die Nutzung des Kartenmaterials von Google Maps und der Einsatz von Ruby on Rails ist ebenfalls vorgesehen. Die Anwendung soll zudem im Browser lauffähig sein, um so auf mehreren Geräten und Plattformen einsatzfähig zu sein. Zur Bedienung sind langfristig bessere Eingabekonzepte als Maus und Tastatur wünschenswert. Hier gibt es mit der Multitouch-Technologie und dem Eye- und Motiontracker weiterführende Möglichkeiten. 2.1 Szenario Das Szenario wurde bereits in den drei eingangs erwähnten Ausarbeitungen vorgestellt. Es beschreibt ein Mehrbenutzersystem auf Kartenbasis als Rich Internet Application. Diese Web-Anwendung soll allen Teilnehmern ortsbezogene Informationen möglichst zeitnah präsentieren. Mit ortsbezogenen Informationen sind in diesem Szenario in erster Linie Positionsangaben (von Menschen oder Fahrzeugen) gemeint. Auf Seite der Teilnehmer soll, beim Einsatz unterschiedlicher Endgeräte, nicht mehr als ein Web-Browser von Nöten sein. 2.2 Ziele Mit Blick auf die Vision ist das Ziel in erster Linie die Evaluation der für Maps on Rails benötigten Techniken im praktischen Einsatz. Dies betrifft vor allem Ruby on Rails und die (Bibliotheken der) Kartendienste Yahoo! Maps [Yahoo! Inc., 2008] und Google Maps [Google Inc., 2007b]. Nach Möglichkeit soll bis zum Ende des Projekts ein aussagekräftiger Prototyp erstellt werden. An diesem soll beurteilt werden, ob und wie eine Integration eines Kartendienstes in einer Ruby on Rails Anwendung gelingen kann.

7 2 Vision Vorgehensweise Zu aller erst soll die zum Arbeiten in der Hochschule für Angewandte Wissenschaften Hamburg nötige Infrastruktur geschaffen werden. Als nächstes soll der Kartendienst Google Maps untersucht werden, um die Möglichkeiten und Grenzen seiner Fähigkeiten in Bezug auf das Szenario zu bewerten. Der folgende Schritt soll das Erkunden von Ruby on Rails und dessen Konzepten sein, sodass eine Integration des Kartendienstes erfolgen kann.

8 3 Evaluierung 4 3 Evaluierung Dieses Kapitel berichtet über die Eignung von und Erfahrungen mit verschiedenen Komponenten, die im Projekt eingesetzt bzw. behandelt wurden. Die Programmiersprache Ruby wird hier nicht erneut behandelt, stattdessen wird auf [Schempp, 2006] verwiesen. Als gutes Nachschlagewerk für Ruby hat sich [Thomas u. a., 2005] erwiesen. Auf die Vorstellung der Komponenten wird hier ebenfalls verzichtet, sofern diese im Rahmen der eingangs erwähnten Ausarbeitungen bereits vorgestellt worden sind. Die Behandlung der Themen der folgenden Unterkapitel erfolgt chronologisch analog zur Bearbeitungsreihenfolge im Projekt. 3.1 Kartendienst Kartendienste gibt es inzwischen verhältnismäßig viele. Doch nur wenige bieten eine API an. Zwei auf den ersten Blick geeignet erscheinende Kartendienste, die auch schon in vielen Mashups genutzt wurden, sind Yahoo! und Google Maps. Beide bieten JavaScript- Bibliotheken, die sich nicht großartig voneinander unterscheiden, für die Einbindung in die eigene Webseite an. Für das weitere Vorgehen wurde Google Maps gewählt. Mit Google Maps lassen sich Marker auf der Karte positionieren, die ein Informationsfenster öffnen können. Diese Marker lassen sich bewegen und löschen. Wichtig zu erwähnen ist, dass die Ortsinformationen für die angezeigten Marker nicht bei Google, sondern in der eigenen Anwendung bzw. Webseite verbleiben. Dieser Punkt war eine der erforderlichen Voraussetzungen für das Szenario. Die bereits durch den Google Maps Dienst [Google Inc., 2007a] im Internet bekannte Geocoding- Funktion (Ortssuche), wird ebenfalls von der API angeboten. Google Maps war nach dieser ersten Einschätzung für die Darstellung der Informationen gut geeignet. Bei ersten Tests stellte sich schnell heraus, dass die API Dokumentation von Google Maps an einigen Stellen Fehler aufweist. Glücklicherweise existieren für viele Funktionen Codebeispiele, an denen man sich orientieren kann.

9 3 Evaluierung Ruby on Rails Für eine Einführung in Ruby on Rails ist das Buch Agile Web-Development with Rails [Thomas und Hannson, 2006] zu empfehlen, das in die Strukturen von Rails einführt. Es behandelt auch Themenbereiche wie das Testen der Anwendung, auf das im Projekt aus Zeitgründen verzichtet wird. An Hand der Beispiele dieses Buches war es möglich, sich mit den grundlegenden Konzepten von Rails vertraut zu machen. Erwähnenswert sind etwa die Migrations, ein Konzept zum Generieren der SQL Data Definition Language. Mit datenbankunabhängigem Ruby-Code kann so das Datenbankschema beschrieben werden, aus dem dann (angepasst an das jeweilige Datenbanksystem) der SQL-Code erzeugt wird, der die Tabellen definiert. Auch Änderungen am Datenbankschema werden unterstützt. Ferner gibt es eine Versionierung des Schemas, das eine Migration sowohl rückwärts als auch vorwärts erlaubt. Durch das Active Record Framework zur Datenbankanbindung erhält man nach der Definition einer Tabelle automatisch Zugriff auf entsprechende Objekte, die jeweils in einer Zeile der Tabelle gespeichert sind. Konstruktoren und Zugriffsmethoden werden dabei gleich mit erstellt. Dank der Namenskonventionen von Active Record wird aus dem Tabellennamen der Klassenname erzeugt, sodass die Klasse direkt genutzt und erweitert werden kann. Active Record unterstützt auch Transaktionen. Rails bringt für die Programmierung von Webseiten mit dynamischem Inhalt eine integrierte Unterstützung der AJAX-Technologie mit, um HTML-Templates für die View (der MVC-Architektur) zu erstellen. Dort können Aktionen für Ereignisse vorgesehen werden, die JavaScript-Code ausführen. Als Unterstützung für die JavaScript-Programmierung bringt Rails das Prototype-Framework 1 mit. 3.3 Google Maps on Rails Hilfestellung bei den ersten Schritten der Integration von Google Maps in eine Ruby on Rails Anwendung sowie einige Anregungen für die Benutzeroberfläche gibt das Buch Google Maps Applications with Rails and Ajax [Lewis, 2007]. Die Einbindung einer Google Maps Karte in eine Ruby on Rails Anwendung ist grundsätzlich kein Problem. Bestimmte Funktionen wie das Zoomen oder das Verschieben des Kartenausschnitts stehen sofort zur Verfügung. Abbildung 3.1 zeigt diesen frühen Zustand einer Anwendung, bei der nur ein paar Bedienknöpfe auf der Karte vorhanden sind. Im Grunde genommen hat die Karte aber noch nichts mit der tatsächlichen Anwendung zu tun, außer 1 Siehe:

10 3 Evaluierung 6 Abbildung 3.1: Eine einfache Google Maps Karte. [Google Inc., 2007a] dass der Kartenausschnitt auf der Webseite dargestellt wird. Noch gibt es z.b. keine Informationen auf der Karte. Um Marker 2 auf einer Karte anzuzeigen, bedarf es einiger JavaScript-Anweisungen. Diese Anweisungen können entweder statischer und das wäre für eine interaktive Anwendung ein schlechter Ansatz oder dynamischer Art sein. Dynamisch bedeutet in diesem Fall, dass der JavaScript Code zur Laufzeit der Anwendung durch Auslösung eines Ereignisses vom Server an den Client geschickt wird, um einen Marker anzuzeigen. Ein Spezialfall davon wäre die Erzeugung eines Markers durch den Benutzer. An dieser Stelle kommt RJS (Remote JavaScript) zum Einsatz: Statt als Antwort auf eine Anfrage des Clients ein (fertiges) Stück HTML zurückzuschicken, wird nun eine JavaScript-Vorlage aufgerufen und an den Client gesendet Yellow Maps for Ruby YM4R 3 ist ein Plugin für Ruby on Rails, das eine kleine API für bestimmte Aktionen wie das Geocoding mitbringt. Mit der YM4R/GM 4 Erweiterung steht eine Ruby-Bibliothek für Rails zur Verfügung. Diese ist nicht ganz vollständig implementiert, ermöglicht aber eine gut strukturierte Ansteuerung und Programmierung der Google Maps Karte. 2 Im Folgenden werden Marker, als einfachster Typ von Informationen, stellvertretend für alle darstellbaren Informationstypen behandelt. 3 Yellow Maps for Ruby [Vellut, 2007a] 4 Yellow Maps for Ruby, Google Maps Plugin for Rails [Vellut, 2007b]

11 3 Evaluierung 7 Es können nun in Ruby Objekte erzeugt werden, die einen Marker in der Google Maps Karte repräsentieren. Die Eigenschaften können etwa aus der Datenbank gelesen werden. Der eigentliche Marker wird aber weiterhin durch JavaScript erzeugt. Dieses kann etwa zur Laufzeit durch den YM4R/GM Plugin erzeugt werden und mit der RJS-Technik an den Client gesandt werden, der daraufhin den Marker darstellt. Leider ist die Implementierung von Y4MR/GM nicht ganz vollständig und sehr stark an der Bibliothek von Google Maps orientiert. Dies führt dazu, dass man doch immer wieder JavaScript-Code selbst schreiben muss. Man bekommt so zum Preis eines hybriden Ansatzes einen schnellen Start in der Anwendungsentwicklung mit Google Maps geboten. 3.4 JavaScript Die Programmierung in JavaScript ist ein Thema für sich, das hier nicht in der Tiefe behandelt werden soll. Mit der objektorientierten und systematischen Programmierung in Sprachen wie Smalltalk oder Ruby hat sie nicht viel gemein. In JavaScript selbst ist ohne die Verwendung von weiteren Frameworks nicht besonders viel zu erreichen bzw. nur auf Umwegen. Jedoch ist JavaScript der einzige Weg ohne zusätzliche Browser-Plugins Programmcode zu schreiben, der in unterschiedlichen Browsern läuft. (Auch wenn es an dieser Stelle durchaus unterschiedliche Interpretationen des Codes durch die Browser gibt.) Durch JavaScript lässt sich die Bibliothek von Google Maps und auch die AJAX-Technologie für die Web-Anwendung nutzen. Ruby on Rails bietet hier durch seine JavaScriptHelper Klassenbibliothek eine gute Hilfestellung bei der Programmierung. 3.5 Google vs. Yahoo! Maps An die Grenzen von Google Maps stößt man, wenn man die Position der Marker per JavaScript verändern möchte. Dies funktioniert in der Benutzeroberfläche per Hand gut. Jedoch gibt es darüber hinaus keine Möglichkeit die einmal gesetzten Eigenschaften eines Markers zu ändern. Der einzige Ausweg ist das Löschen und das anschließende neue Erstellen eines Markers. Dabei müssen allerdings alle EventListener, die zu einem Marker gehören, mit gelöscht werden, um so alle Referenzen auf gelöschte Marker zu vernichten. Einen Schritt weiter gedacht, stellt man dann fest, dass ein Marker und dessen Referenz nur auf dem Client existieren, sodass man keine Möglichkeit hat, ihn direkt vom Server aus zu löschen. Das ist nicht einmal möglich, wenn man die Referenz des Markers hätte, da diese auf jedem weiteren Client einen anderen Wert besitzt.

12 3 Evaluierung 8 Google Maps erlaubt es an dieser Stelle nicht einen einmal gesetzten Marker zu ändern bzw. zu löschen. Zwei Auswege gibt es jedoch. Die Erste wäre das Löschen aller Marker und das anschließende neue Erstellen aller Marker, was jedoch äußerst unzufriedenstellend ist. Die Zweite wäre ein Framework in JavaScript, das einem Objekt bzw. Marker einen eindeutigen Bezeichner zuordnet. So kann der Server dem Framework auf der Clientseite den Objekt- Bezeichner und die jeweilige Nachricht übergeben, die dann lokal auf jedem Client umgesetzt wird. Doch auch diese Lösung ist im Rahmen des Projekts keine zufriedenstellende Lösung, da sie mit einem zu großen Aufwand verbunden ist und in JavaScript durchgeführt werden muss. Hier lohnt sich ein Blick auf die Bibliothek von Yahoo! Maps. Dort gibt es zwar weniger Konfigurationsmöglichkeiten und auch keine Möglichkeit den Marker von Hand zu verschieben. Doch diese Funktionalität ist an dieser Stelle zu vernachlässigen. Der entscheidende Unterschied ist, dass das Kartenobjekt von Yahoo! Maps eine Liste von Markern führt, deren Namen bzw. Bezeichner man selbst bei der Markererstellung vergeben kann. So kann jedem Marker ein eindeutiger (und globaler) Bezeichner zugeordnet werden, auf den bei Bedarf auch zugegriffen werden kann. Dies ist bei dem beschriebenen Problem das Löschen eines einzelnen Markers von entscheidendem Vorteil, da nun wirklich nur dieser eine Marker betroffen ist und alle anderen Marker davon unberührt bleiben. Daraus ergeben sich drei Vorteile: Eine bessere Performance auf dem Client, eine geringere Datenmenge für die Übertragung zum Client und eine progammiertechnisch gesehen schöne, einwandfreie und direkte Umsetzung. Die beschriebene Schwierigkeit war der Grund, die Entwicklung fortan mit Yahoo! Maps weiterzuführen. Ein anderes Problem betraf die Programmierung der Aktionen für den Links-Klick und den Doppelklick mit der Maus. Die Bibliotheken von Google als auch von Yahoo! waren nicht in der Lage einen Doppelklick korrekt zu erkennen. An Stelle eines Doppelklicks wurden zwei einzelne Klicks und ein Doppelclick ausgeführt, was je nach Funktionsbelegung zu einer größeren Verwirrung bei der Bedienung führen kann. Hier ist, wie an so mancher Stelle, ein wenig Nacharbeit notwendig. Ein Lösungsweg ist die verzögerte Ausführung des einfachen Linksklicks, der bei einem Doppelklick abgefangen wird und so nicht ausgeführt werden kann. 3.6 Aktualisierungsstrategie Ein zentraler Punkt, den es zu klären galt, betrifft die Verteilung der aktualisierten Daten an alle Clients, sodass jeder Client den gleichen, aktuellen Datenbestand vorliegen hat. Da es sich bei Maps on Rails um eine Web-Anwendung handelt, müssen Anfragen für eine

13 3 Evaluierung 9 Aktualisierung vom Client an den Server geschickt werden. Dieser kann nicht von sich aus tätig werden. Die aktuellen Daten können nur auf Anfrage eines Clients an (ausschließlich) diesen versendet werden. Im ersten Schritt wird jedem Marker die Zeit seiner letzten Veränderung zugeordnet. So kann bei jeder Veränderung des Datenbestandes die aktuelle Zeit auf den Client übertragen werden. Bei der nächsten Aktualisierung kann der Server dann abgleichen, ob der Zeitstempel des Clients mit dem größten Zeitstempel aller Marker übereinstimmt. Falls nicht, müssen alle Marker, deren Zeitstempel größer als der des Clients ist, aktualisiert werden. Im zweiten Schritt muss dem Fall Rechnung getragen werden, dass auf den Clients (noch) Marker existieren können, die inzwischen von einem anderen Teilnehmer gelöscht worden sind und deshalb aus der Datenbank des Servers verschwunden sind. Diese Marker werden in dem zuerst genannten Schritt nicht erfasst (da für sie kein Zeitstempel vorliegt). Es ist also nötig, bei der Aktualisierungsanfrage eines Clients, zusätzlich zum Zeitstempel auch eine Liste mit Bezeichnern der Marker mitzusenden. Durch den Abgleich dieser Liste mit der Marker-Datenbank des Servers kann auch dieses Problem behoben werden. Für die Antwort des Servers auf das Ergebnis einer Aktualisierungsanfrage des Clients gibt es demnach folgende Möglichkeiten: Kein Zeitstempel (auf Server oder Client) vorhanden: Komplette Aktualisierung aller Marker Die Daten sind aktuell (Zeitstempel gleich): Aktualisierung mit leerem Inhalt Der Zeitstempel des Clients ist älter als der des Servers: Neuere Marker aktualisieren Für die beiden letzen Fälle muss zusätzlich geprüft werden, ob es Marker gibt, die nur auf dem Client existierenden: Diese Marker müssen gelöscht werden. Der Zeitstempel des Clients ist neuer bzw. jünger als der des Servers: Dieser Fall kann nur vorkommen, wenn der Marker mit dem größten Zeitstempel gelöscht wurde. Er wird durch die vorhergehende Prüfung ebenfalls abgefangen und muss daher nicht gesondert behandelt werden. Die Aktualisierungsstrategie stellt die Grundlage für den Einsatz von Maps on Rails als Mehrbenutzersystem dar. Durch sie wird, ohne dass der Server Zustandsinformationen über irgendeinen Client speichert, der aktuelle Zustand an alle Clients übertragen. Dabei werden ausschließlich die für den Client nötigen Informationen (nur die Veränderungen) übertragen. Die Übertragung der Änderungen erfolgt mittels Remote JavaScript-Technik. Die Antwort auf die AJAX-Anfrage des Clients ist JavaScript-Code, der auf dem Client ausgeführt wird, um die Änderungen in der Karte vorzunehmen.

14 3 Evaluierung 10 Die Aktualisierung wird von den Clients periodisch ausgeführt und macht so eine Kartenanwendung mit sich dynamisch ändernden Daten möglich. Sofern nur statische Marker dargestellt würden, wäre ein solcher Algorithmus nicht notwendig. Viele derartige statische Web-Anwendungen finden sich im Internet. Manche von ihnen aktualisieren alle Marker in periodischen Abständen, bei anderen muss dies durch ein Neuladen der Seite bzw. Anwendung manuell geschehen. Während der Entwicklungsphase war es ohne Probleme möglich, mit einigen Browsern zugleich auf die Anwendung zuzugreifen. Ohne das Ergebnis genauer zu erläutern, hat der Web-Server auf dem Entwicklungsrechner ca. 40 Anfragen pro Sekunde bearbeiten können. Eine konkrete Aussage über die Performanz des Systems kann hieraus, auf Grund unzureichender und ungesicherter Informationen über die Rahmenbedingungen, sicher nicht gefolgert werden. 3.7 Yahoo! Maps on Rails Die Entwicklung von Maps on Rails auf Basis von Yahoo! Maps musste nun ohne den YM4R/GM Plugin voran gehen, da dieser nur für Google Maps geeignet war. Wie sich schnell herausstellte, lässt sich in relativ kurzer Zeit mit den Helpern von Rails ein guter Ersatz erstellen. Darauf wird im folgenden Unterkapitel eingegangen. Der Einsatz von Yahoo! Maps erforderte einige Änderungen in der Umsetzung der Anwendung. So war es beispielsweise nicht mehr nötig für jedes Mausereignis einen eigenen Event- Listener zu schreiben. Die Funktionalität fällt an dieser Stelle geringer aus. Jedoch werden diese Listener automatisch erzeugt und so bleibt einem die relativ umständliche Definitionen der Listener in JavaScript erspart. Ein Mehraufwand ist hingegen bei der Gestaltung der Benutzeroberfläche nötig. Yahoo! erlaubt keine editierbaren Eingabefelder in den Informationsfenstern, sodass die Editiermasken ausserhalb der Karte dargestellt werden müssen. Dies ist für eine Eingabe von wenigen Informationen sicher ein Nachteil. Bei der Eingabe von mehreren Eigenschaften kann es aber auch ein Vorteil sein, da die Eingabe von der aktuellen Darstellung auf der Karte entkoppelt wird. Wenn etwa eine Aktualisierung des Karteninhalts stattfindet, bleibt die Eingabemaske davon unberührt und der Benutzer kann seine Eingabe fortsetzen, ohne dabei unterbrochen zu werden. Abbildung 3.2 zeigt ein Bild des aktuellen Prototypen. Auf die grafische Gestaltung wurde, zugunsten der Funktionalität im Rahmen des Projekts, kein großer Wert gelegt. Zu erkennen sind verschiedene Marker auf der Karte und eine Bedienleiste im oberen Kartenbereich. Am rechten Bildrand ist eine Informationsleiste vorgesehen, die bisher aber nur sehr rudimentär umgesetzt worden ist. Unter der Karte besteht die Möglichkeit die Ortssuche einzusetzen.

15 3 Evaluierung 11 Abbildung 3.2: Der Prototyp Maps on Rails während der Entwicklung.

16 3 Evaluierung 12 Alle anderen Knöpfe am unteren Bildrand dienen der Entwicklung und sind nicht weiter zu beachten Rails Helper Ruby on Rails bietet die Möglichkeit sogenannte Helper für den Gültigkeitsbereich eines Controllers zu definieren. Hier lassen sich bestimmte Funktionalitäten kapseln, etwa wiederkehrende Aktionen oder, wie in diesem Fall umgesetzt, die Generierung des JavaScript- Codes. Der Helper stellt eine Art spezialisierte Ruby-Bibliothek dar, die (zur Laufzeit aufgerufen) den nötigen JavaScript-Code für die Ansteuerung der Karte erzeugt. Dieser JavaScript-Code kann an einer Stelle gekapselt werden. Die Kapselung ermöglicht eine saubere Trennung zwischen JavaScript und Ruby-Code, sowie zwischen der Steuerung des Programmablaufs und der Anzeige. Durch diese Trennung wird auch die Übersichtlichkeit des Quellcodes gefördert. In der View kann dann auf die (an anderer Stelle gekapselte) Funktionalität für die Steuerung des Programmablaufs zugegriffen werden, um den nötigen Code per Remote JavaScript an den Client zu senden. Die eigentliche Aufgabe der View, die die Erzeugung der Anzeige auf dem Client betrifft, bleibt davon weitestgehend unberührt. Diese Trennung der Belange entspricht auch der Einhaltung des Model-View-Controller Architekturmusters. 3.8 Web-Browser Im Rahmen des Projekts wurde ein kurzer Test der Anwendung in verschiedenen Browsern vollzogen. Die Anwendung lief in Firefox 2.x und Safari 3.x ohne Probleme. Im Internet Explorer 7 und Opera 9.x gab es geringe Abweichung bei der Darstellung. Die Anwendung funktionierte jedoch erstaunlicherweise in vollem Umfang. Je nach weiterer Ausführung des Projektes sind hier aber durchaus Probleme zu erwarten.

17 4 Wirtschaftskontakte 13 4 Wirtschaftskontakte 4.1 Geoinformationsysteme der Stadt Hamburg Im Rahmen des Projekts kam ein Besuch beim Landesamt für Geoinformation und Vermessung der Stadt Hamburg zu Stande. Dort beschäftigt man sich auch mit einer sehr ähnlichen Thematik, aber bedient sich einer völlig anderen technischen Umsetzung. Man kann den dort gewählten Weg gewissermaßen als professionellere Herangehensweise betrachten. Dieses Unterkapitel soll kurz auf die Rückschlüsse für das Projekt eingehen. Kartendienste wie Google oder Yahoo! Maps bieten bei weitem nicht den Funktionsumfang eines professionellen Geoinformationssystems. Die Kartendienste sind am Endbenutzer orientiert und bieten beispielsweise eine gute Ortssuche und Routenplanung. Professionelle Systeme basieren auf anderen Techniken und sind nicht über eine verhältnismäßig einfache JavaScript-Bibliothek einzubinden. Es gibt Lösungen, die auf den Standards des OGC 1 basieren und auf den Web Map Service (WMS) und den Web Feature Service (WFS) aufbauen. Beides sind Web-Services. WMS beschreibt den standardisierten Zugriff auf Kartenmaterial. WFS beschreibt den Zugriff und die Manipulation von geographischen bzw. raumbezogenen Daten. Um ein System zu bauen, das auf diesen Web-Services aufbaut, müssen eigene Server für diese Dienste betrieben werden 2. Das Kartenmaterial kann sicher aus einer bestehenden Quelle bezogen werden, aber die darzustellenden Daten müssen durch einen speziellen Dienst zur Verfügung gestellt und persistent gemacht werden. Dieser Dienst muss selbst aufgesetzt werden, da die Daten (nach den Anforderungen an das Szenario) im eigenen System und nicht bei einem anderen Anbieter gespeichert werden sollen. I.d.R. werden bei solchen Systemen Karten und Daten zusammen in einer Ebene angezeigt, sodass dabei ein wenig Interaktivität der Anwendung verloren geht 3. Der große Vorteil solcher standardisierter Dienste liegt in ihrer Interoperabilität und der Offenheit der Standards. Im Vergleich zu den proprietären Lösungen von Google und Yahoo! Maps, die zudem weitere (auch lizenzrechtliche) Nutzungeinschränkungen mit sich bringen, 1 Open Geospatial Consortium, siehe 2 Für entsprechende Dienste, siehe 3 Man denke dabei an die verschiebbaren Marker von Google Maps.

18 4 Wirtschaftskontakte 14 Abbildung 4.1: Satellitenbild des OpenLayers-Kartendienstes. [OSGeo, 2008] gibt es auch freie Kartendienste. Abbildung 4.1 zeigt den freien Kartendienst OpenLayers, der ebenfalls eine JavaScript API zur Verfügung stellt. Auf Grund des begrenzten zeitlichen Rahmens des Projekts werden diese Ansätze hier nicht weiter vertieft. Ferner liegt das Hauptaugenmerk des Projekts nicht auf der Evaluation verschiedener Geoinformationsysteme und deren Kartenmaterial, sondern auf Entwicklung eines Ruby on Rails Systems mit wenn man so will, irgendeinem, Kartendienst. 4.2 UbiLabs Im Rahmen eines Vortrags des GameCityLabs, in dem wir unsere Projekte im Collaborative Workplace der Hochschule für Angewandte Wissenschaften Hamburg vorstellten, kam ein Kontakt mit der Firma Ubilabs 4 zustande. Ubilabs entwickelt verschiedene Mashup- Anwendungen mit Google Maps und setzt seit Neuestem auch Ruby on Rails ein. Eine weiterführende Zusammenarbeit im Rahmen der Masterarbeit ist angedacht. 4 Siehe:

19 5 Zusammenfassung 15 5 Zusammenfassung Dieser Bericht steht in Zusammenhang mit den Arbeiten am Leitstandszenario im Seminar, Anwendungen I und Anwendungen II. In Kapitel 2 wurden zuerst die Vision, die Ziele und die Vorgehensweise vorgestellt. Kapitel 3 beschreibt die evaluierten Techniken mit ihren Möglichkeiten und Grenzen und diskutiert einige Überlegungen, die zur Erstellung des Prototypen notwendig waren. In diese Kategorie fallen etwa Ruby on Rails, JavaScript bzw. AJAX, Google und Yahoo! Maps und die Anwendung Maps on Rails selbst. 5.1 Fazit Abschließend kann festgestellt werden, dass das Projekt erfolgreich gelaufen ist und das Resultat im gewünschten Bereich liegt. Aufgrund des beschränkten zeitlichen Rahmens nahmen der Aufbau der Infrastruktur im Labor und die Einarbeitungszeit in die Techniken einen überproportional großen Teil der Projektzeit ein. Die Evaluation der diskutierten Techniken im Rahmen des Szenarios war erfolgreich. Es ist mit einer gewissen Einarbeitungszeit möglich eine interaktive Kartenanwendung prototypisch mit Ruby on Rails als Web-Anwendung umzusetzen, wie das Arbeitsergebnis des Projekts zeigt. Wünschenswert wäre eine noch tiefergehende Beschäftigung mit dem Ruby on Rails Framework gewesen. Einige Aspekte wie z.b. das Testen konnten im Projekt leider nicht betrachtet werden. Auf jeden Fall war das Arbeiten mit Ruby on Rails angenehm und motivierend. Die Programmierung in JavaScript war des Öfteren sehr mühsam und relativ kompliziert, da einfache Dinge oft nicht auf dem direkten Weg zu erreichen waren. Sicherlich spielte hier auch die mangelnde Erfahrung in der Programmierung von JavaScript eine Rolle. Der Einsatz der Kartendienste war eng mit den Schwierigkeiten von JavaScript verbunden, gestaltete sich aber relativ problemlos. Nichtsdestotrotz wäre das ein oder andere Mal eine bessere Unterstützung durch die Bibliotheken der Kartendienste sinnvoll gewesen. Dies trifft beispielsweise bei der Gestaltung von Eingabemasken innerhalb des Kartenausschnitts und insbesondere bei der Manipulation von bestehenden Markern zu. Hier besteht für die weitere Entwicklung der Bibliotheken der Kartendienste noch genügend freies Potential.

20 5 Zusammenfassung Ausblick Nachdem hier gezeigt wurde, dass die Integration eines Kartendienstes in Ruby on Rails in einer gewinnbringenden Art und Weise möglich ist, kann das Thema in der anstehenden Masterarbeit weiter vertieft werden. Mehrere Punkte sind noch nicht behandelt worden und an einigen Stellen gibt es noch Verbesserungsbedarf. Eine kleine Auswahl anzugehender Bereiche sind die Integration einer Benutzerverwaltung, die Nutzung einer Datenbank mit Geoinformations-Erweiterung, die Darstellung von Flächen mittels Polygonen und die Verbesserung des User-Interfaces. Hier ist z.b. auch an Usability-Tests zu denken. Weitere interessante Gebiete sind die Nutzung eines freien Kartendienstes (z.b. Open- Layers) und die Steuerung von Maps on Rails mit neuen Eingabegeräten wie Multitouch, Eyetracker und Motiontracker, sofern dies für einen Einsatz in einer Einsatzleitstelle an einer Powerwall einen Sinn ergibt. Die Anwendung Maps on Rails kann im Zuge dieser Umsetzungen weiter ausgebaut werden. Dabei soll der Schwerpunkt aber noch stärker auf der Evaluation von Ruby on Rails liegen.

21 Literaturverzeichnis [Google Inc. 2007a] GOOGLE INC.: Google Maps URL google.de/. Zugriffsdatum: [Google Inc. 2007b] GOOGLE INC.: Google Maps API URL google.com/apis/maps/. Zugriffsdatum: [Hansson 2008] HANSSON, David H.: Rails Framework Documentation URL Zugriffsdatum: [Lewis 2007] 2007 LEWIS, Andrew: Google Maps Applications with Rails and Ajax. Apress, [OSGeo 2008] OSGEO, Open Source Geospatial Foundation: OpenLayers URL [Schempp 2006] SCHEMPP, Ruben: Aktuelle Entwicklungen im Bereich von Programmiersprachen, Hochschule für Angewandte Wissenschaften Hamburg, Bachelorarbeit, URL arbeiten/bachelor/schempp.pdf [Schempp 2007] SCHEMPP, Ruben: Anwendungen I: Verteilte Web-Anwendungen mit Ruby URL de/~ubicomp/projekte/master2007/schempp/bericht.pdf. Zugriffsdatum: [Schempp 2008a] SCHEMPP, Ruben: Anwendungen II: Interaktive Karten als Rich Internet Applications URL de/~ubicomp/projekte/master07-08-aw/schempp/bericht.pdf. Zugriffsdatum: [Schempp 2008b] SCHEMPP, Ruben: Seminar: Maps on Rails URL master07-08/schempp/bericht.pdf. Zugriffsdatum: [Thomas u. a. 2005] THOMAS, Dave ; FOWLER, Chad ; HUNT, Andy: Programming Ruby: The Pragmatic Programmers Guide. Second Edition. The Pragmatic Programmers, ISBN

22 Literaturverzeichnis 18 [Thomas und Hannson 2006] THOMAS, Dave ; HANNSON, David H.: Agile Web- Development with Rails. Pragmatic Bookshelf, 2006 [Vellut 2007a] VELLUT, Guilhem: Yellow Maps for Ruby URL rubyforge.org/projects/ym4r/. Zugriffsdatum: [Vellut 2007b] VELLUT, Guilhem: Yellow Maps for Ruby, Google Maps Plugin for Rails URL Zugriffsdatum: [Yahoo! Inc. 2008] YAHOO! INC.: Yahoo! Maps API URL yahoo.com/maps/ajax/v3.7/reference.html. Zugriffsdatum: