@leo's

Was soll ich dazu noch sagen! Webdesign ist nicht einfach!

[via macerkiste]

In den letzen Semesterferien konnte ich für Stefan F. Keller, respektive dessen Institut int>e>gis, während einer Woche ein Projekt realisieren. Der Projektauftrag lautete Geodaten aus Wikipediaeinträgen zu extrahieren, zu speichern und anzuzeigen.

Das Programm sollte auf dem Toolserver laufen. Der Toolserver ist ein Server der deutschen Mediawiki Foundation welcher von Sun gesponsert wurde. Auf diesem Server sind die Wikipedia-Datenbanken gespiegelt und er steht interessierten Entwicklern offen um Programme zur Weiterentwicklung von Mediawiki auszuprobieren.

Leider haben wir uns mit dem Entscheid für den Toolserver zu entwickeln auch einige Probleme eingehandelt. Zuerst hatten wir bei Projektstart keinen Login für den Server zur Verfügung was uns zwang zuerst auf einem lokalen Testserver zu entwickeln. Bereits bei der lokalen Entwicklung ergaben sich einige Problem. Da die Mediawiki-Software, welche Wikipedia betreibt, in PHP geschrieben ist wurde unser Projekt ebenfalls mit PHP entwickelt in der Hoffnung einige Mediwiki-Funktionen weiter zu verwenden. PHP erwies sich allerdings für diese Art von Projekt als relativ ungünstige Wahl da der PHP Garbage Collector nur sehr ungenügende Funktionalitäten bereit stellt.

Gegen Ende des Projekts stand dann der Zugang zum Toolserver bereit. Die Überaschung war dann um so grösser als ich dort Solaris als Betriebsystem antraf. Leider wurden auch nicht alle Daten des Wikipediaprojektes gespiegelt. Da einige Texte der Wikipedia-Datenbank ins Filesystem ausgelagert werden (der Grund dafür ist mir bis heute nicht bekannt) können diese nicht gespiegelt werden. Ich musste desshalb unser Tool so umprogrammieren das es die Daten über den Wikiproxy, einem Tool von Daniel Kinzler welches dieses Problem umgeht, geladen wurden. Dies sorgte natürlich für eine wesentlich schlechtere Performance.

Selbstverständlich habe ich auch etwas gelernt. Die "Lesson Learned" für dieses Projekt sind:

• Früh deployen oder gar auf Zielsystem entwickeln
  
• Bei kurzer Projektdauer müssen alle Ressourcen zu Beginn des Projekts bereitstehen
  
• Wenn externe Datenbestände nötig sind ist deren Richtigkeit und Vollständigkeit möglichst früh abzuklähren
  
• PHP eignet sich wegen ungenügendem Garbage Collector nur sehr eingeschränkt für lang laufende Skripte

Selbstverständlich sind die Resultate dieses Projekt auch Online einsehbar. Die Tabelle mit den Wikipedia-Koordinaten kann eingesehen werden. Ebenso ist es möglich Daten aus einer Koordinaten-Box auszugeben, wobei bei dieser Anfragen ist die Ausgabe aus Performancegründen auf tausend Punkte limitiert ist. Ebenso ist es möglich die fehlerhaften Koordinaten auszugeben, um diese Fehler zu korrigieren. Hier werden natürlich auch die Absichtlich falsch eingegeben Koordinaten, z.B. für Vorlagen, ausgegeben.

Und noch ein wenig off-topic: Viel einfacher währe es natürlich wenn wir die (Geo-)Daten vom Staat einfach bekomen würden, schliesslich haben wir mit unseren Steuergeldern bereits für deren Erhebung bezahlt. Mehr dazu hier und gleich bei der Petition für freie Geodaten mitmachen.

Wie der Herr Graf unlängst in seinem Blog festgestellt hat sollte ein Informatiker auch noch ein Kommunikationsexperte und ein Prozessanalytiker sein. Denn oft scheitern, vorallem kleinere, Informatikprojekte daran das gar nicht klar ist was der Kunde eigentlich will.

Das kommt zum einten davon das der Kunde nicht klar kommunizieren kann was er will und der Informatiker dem Kunden nicht hilft das Problem zu formulieren weil er lieber über Techologien als Lösungen spricht. Diese Technologie-Mentalität ist bereits so weit in den Köpfen verankert das der Kunde mit Schlagwörter, Produkten und Technologien anstelle von Problemen auf die Informatikfachkraft zukommt. Desshalb ist es wichtig den Kunden bereits von Beginn weg klar zu machen das man sein Problem möglichst gut verstehen möchte und ihm so lange zuhört bis man es auch wirklich verstanden hat. Sollte der Kunde an der Technik intressiert sein, sollte ihn darauf hinweisen das es am Beginn eines Projektes noch zu früh ist um über Technologien zu sprechen. Binden sie ihn aber dann bei der Lösungsfindung ein und kommunizieren sie aktiv.

Der andere, mindest ebenso häufig vorkommende Fall ist das mit Software versucht wird einen nicht durchdachten Prozess zu optimieren. Doch ein Prozess der schon ohne Software nicht richtig funktioniert weil er zu wenig durchdacht ist oder weil er zu wenig gut dokumentiert und kommuniziert ist wird auch mit einer noch so guten Software nicht zu verbessern. An dieser Stelle muss der Informatiker, auch wenn es eigentlich nicht sein Job ist, versuchen den Prozess zu definieren und zu optimieren.

(Intressant das ich bei solchen Texten automatisch in die Höfflichkeitsform wechsle ;-) )