jensjaeger.com

Eine Suchmaschine ist eine Software, die Verfahren des Information Retrieval implementiert. Sie dient zur Informationsfilterung von Dateien, die in einem Computersystem abgelegt sind. Eine Suchmaschine erstellt einen Index für die Datenbasis, um Suchanfragen für jeden Suchbegriff mit einer nach Relevanz geordneten Ergebnisliste zu beantworten. Dieser Index ist vergleichbar mit einem Index-Objekt eines Datenbanksystems. Nach Eingabe eines Suchbegriffes zeigt die Suchmaschine eine Liste mit Verweisen auf relevante Dokumente. Meistens werden die Suchergebnisse mit dem Titel des Dokuments und einem mit dem Suchbegriff enthaltenen Auszug aus dem Dokument dargestellt. Suchmaschinen haben drei wesentliche Aufgabenbereiche: 

• Generierung, Aktualisierung und Optimierung einer Datenstruktur mit Informationen über die zu durchsuchenden Dokumente. Diese Datenstruktur wird Index genannt.
• Verarbeitung der Suchanfragen und ordnen der Ergebnisse anhand der Relevanz des indizierten Dokumentes zum Suchbegriff.
• Aufbereitung und Darstellung der Ergebnisse in einer Form, die vor allem den Kriterien: Erwartungskonformität, Aufgabenangemessenheit und Selbstbeschreibungsfähigkeit entspricht.

Nach der von Jakob Nielson erstellten und zuletzt im Jahr 2007 aktualisierten Liste mit den zehn schlimmsten Fehlern im Webdesign ist eine schlechte Suche der zurzeit am Häufigsten gemachte Fehler auf Webseiten. In Search: Visible and Simple beschreibt Jakob Nielsen die Gründe, warum Anwender Suchfunktionen auf Webseiten erwarten. Diese sind:

• Anwender wollen nicht die Navigation einer Seite benutzen. Sie wollen nur das finden, was sie interessiert.
• Die Suche bietet einen Ausweg wenn sich die Anwender in der Navigationsstruktur verloren fühlen und nicht weiter wissen.

Daraus ergibt sich, dass auf größeren Webauftritten eine Suchmaschine, aus Gesichtspunkten der Usability, ein unverzichtbarer Bestandteil ist. Jedoch ist die Implementierung einer Volltextsuchmaschine und die sinnvolle Gewichtung der zu durchsuchenden Inhalte sehr aufwendig.

Als Stammformreduktion bezeichnet man im Information Retrieval ein Verfahren, mit dem verschiedene Varianten eines Wortes auf ihren gemeinsamen Wortstamm zurückgeführt werden. So sollen bei einer Suche nach test auch Ergebnisse zu finden sein, die zum Beispiel die Begriffe tested, tests oder testing enthalten.

Zur Stammformreduktion gibt es unterschiedliche Algorithmen für verschiedene Sprachen. Die Entwicklung eines Algorithmus zur Stammformreduktion ist eine experimentelle Wissenschaft, da dieser nicht mathematisch verifiziert werden kann, sondern an realen Texten getestet werden muss.

Man verfolgt mit der Stammformreduktion zwei Ziele:

1. Durch das Zusammenführen verschiedener Wortformen zu einem Wort tritt dieses tendenziell häufiger auf. Es sollten deshalb mehr Dokumente bei einem Suchbegriff gefunden werden.
2. Durch die Zusammenführung verschiedener Wortformen zu Einem, werden Listen mit Verweisstrukturen auf die zu indizierenden Dokumente kleiner, da weniger Wörter verwaltet werden müssen.

Stammformreduktion ist immer sprachenabhängig, da je nach Sprache unterschiedliche grammatikalische Regeln für Wortkomposition, Flexion und das Hinzufügen von Affixen (Präfix, Suffix und Infix) gelten, die unterschiedliche Algorithmen erfordern.

Der 86. Kandelmarsch fand im Rahmen der Absolventenverabschiedung der Hochschule Esslingen am 25. Juli 2008 statt. Dabei ziehen die Absolventen der Hochschule Esslingen mit Frack, Zylinder und einer Holzleiter durch die Esslinger Innenstadt. Wie im Jahr 1922 marschieren die Befrackten im Kandel - immer ein Fuß auf dem Gehweg und einer auf der Straße.

[Show as slideshow]

Ein Zip-Archiv mit allen Bilder gibt es hier (53,4MB).

Die Hochschule hat auch einen Bericht über den Kandelmarsch ins Netz gestellt.

Information Retrieval (IR) ist ein Fachgebiet der Informatik, das die inhaltliche Suche nach Informationen in Dokumentensammlungen untersucht und Modelle, Methoden und Verfahren dafür entwickelt. Der Begriff Information Retrieval wurde 1950 von dem amerikanischen Informatikpionier Calvin Northrup Mooers geprägt. Es existiert keine eindeutige Definition des Begriffes. Die Fachgruppe Information Retrieval der Gesellschaft für Informatik beschreibt den Begriff folgendermaßen:

Diese Definition ist sehr allgemein gehalten. Es wird die Vagheit oder Unschärfe betont. Zur Bewertung soll die Nützlichkeit herangezogen werden. Es wird also versucht, aus gespeichertem Wissen in Form einer Datenbasis den Informationsbedarf eines Benutzers zu befriedigen. Dabei spezifiziert der Benutzer eine Anfrage, die die erwartete Antwort nur grob charakterisieren muss. Das IR-System versucht dann diejenigen Informationen in der Datenbasis ausfindig zu machen, die Relevanz für diese Anfrage aufweisen. Dabei können eventuell mehrere Benutzerinteraktionen notwendig sein, bis ein endgültiges Ergebnis vorliegt. Zur Bewertung der Ergebnisse hinsichtlich ihrer Relevanz ist ein Bewertungsverfahren nötig, mit dem sich die Qualität der Ergebnisse feststellen lässt.

Einführung

Ein Widget ist ein Computerprogramm, das nicht als eigenständige Anwendung betrieben wird, sondern in eine grafische Benutzeroberfläche oder Webseite eingebunden ist. Widgets stellen Dienste oder auch nur Informationen zur Verfügung. Sie benötigen eine Umgebung, die dem Widget Grundfunktionen und Ressourcen bereitstellt und seine Möglichkeiten beschränkt. Programme, die speziell dem Betrieb von Widgets dienen, werden auch als WidgetEngine bezeichnet. 

Der Begriff „Widget“ erlangte 2003 durch das Programm Konfabulator weite Verbreitung, das 2005 von Yahoo gekauft wurde. Populär wurde das Konzept durch die Einführung der Version 10.4 (April 2005), des Betriebssystems Mac OS X, durch Apple. Das Betriebsystem wurde mit dem Programm Dashboard ausgliefert, einer Widget Engine für in HTML, CSS und JavaScript entwickelte Widgets. Das im Januar 2007 erschienene Betriebsystem Windows Vista der Firma Microsoft enthält ebenfalls eine Widget Engine. 

Parallel zur Entwicklung von Widgets für einzelne Betriebssysteme entwickelten sich Widgets in Form von Webanwendungen. Viele dieser Widgets bieten keine komplexen Funktionen, sondern blenden lediglich Informationen aus anderen Quellen ein (Syndikation). Beispiele dafür sind die Einbindung von Inhalten von Portalen wie YouTube oder Flickr. Diese Arten von Widgets haben mit zur Verbreitung von User Generated Content und Web 2.0-Anwendungen beigetragen.

Es gibt momentan keinen einheitlichen Standard für Widgets. Daher muss für jede Plattform eine eigene Implementierung erstellt werden, was einen erheblichen Mehraufwand bedeutet. Eine Alternative sind Dienstleister die ein Widget für verschiedene Plattformen automatisch zur Verfügung stellen wie zum Beispiel der Anbieter Netvibes . Das Internetstandardisierungsgremium W3C arbeitet jedoch an einem einheitlichen Standard für Widgets (W3C). Es bleibt abzuwarten in wie weit sich dieser durchsetzen wird. 

Widgets stellen ein Hilfsmittel dar, um Informationen von verschiedenen Quellen auf einer Webseite zu aggregieren. Damit sind sie ein logischer Nachfolger der Portlet Technolgie mit dem Unterschied, dass die Aggregation clientseitig erfolgt und nicht serverseitig.

Im Zuge des Web 2.0 wird die Integration von Inhalten immer wichtiger. Daher haben wir für Journizer ein Widget entwickelt. Dabei wurde die Netvibes API gewählt, um das Widget möglichst vielen Plattformen zur Verfügung zu stellen. 

Aufbau des Journizer Widgets 

 
Im Moment unterstützt Netvibes außer seiner eigenen Plattform iGoogle, Apple Dashboard, Opera, Windows Vista und Windows Live. Technisch stützt sich ein Netvibeswidget auf XML und Javscript. Die Kommunikation zwischen den Komponenten ist in folgender Abbildung dargestellt. 

1. Journizer hat das Journizer Widget auf der Netvibes Plattform veröffentlicht. Dazu wird eine URL bereitgestellt die das Grundgerüst des Widgets liefert.
2. Der Nutzer installiert das Journizer Widget auf einer unterstützten Widget-
   Plattform, zum Beispiel Apple Dashboard.
3. Das Widget lädt seine Inhalte über Netvibes vom Journizer Server.

Das Widget besteht aus einer XML Datei die das Grundgerüst bildet sowie Javascriptlogik die für das Nachladen von den Inhalten zuständig ist. Das Widget soll den aktuellen Status eines Journizers darstellen. Dies beinhaltet den Namen, die Mission und seinen Aufenthaltsort. Letzteres wird zusätzlich durch eine Weltkarte visualisiert dargestellt. Den kompletten Inhalt lädt das Widget als HTML Fragment über Netvibes von Journizer Server. Das ganze sieht dann folgendermassen aus:
 

Auf meiner Journizer Seite gibt es die Links zur Installation des Widgets auf Verschiedenen Plattformen.

Zusammenfassung

Die Widgettechnologie stellt einen wichtigen Schritt zur Integration verschiedener Inhalte auf einer Webseite dar. Durch entsprechende APIs, wie die der Netvibes Plattform, ist es relativ einfach Widgets für verschiedene Plattformen zur Verfügung zu stellen. Es bleibt abzuwarten in wie fern sich ein einheitlicher Standard durchsetzen wird.

Messen

Eine der wichtigsten Dinge bei UDD ist das Messen. Jeder Entwickler muss die Zeit messen die für eine Iteration benötigt wird und mit der geschätzten Zeit vergleichen. Am Anfang eines Projektes werden diese Schätzungen noch relativ viele Fehler enthalten. Im Verlauf des Projektes werden die Schätzungen jedoch mit jedem Planungsspiel besser werden. Die Geschäftsseite bekommt so genaue Prognosen welche Funktionen bis zum jeweils nächsten Planungsspiel umgesetzt werden können.

Dokumentation

Eine der am Häufigsten genannten Kritikpunkte aller agiler Methoden ist, dass nicht ausreichend auf Dokumentation geachtet wird. Es gibt in UDD keine Phase Dokumentation. Die Dokumentation wird während allen Phasen des Projekt erstellt. Die erstellten Quelltexte sollen nach den Prinzipien des selbstdokumentierenden Quellcodes erstellt werden. Eine genaue Erklärung über selbstdokumentierenden Quellcode findet sich in Kapitel 19 von Code Complete. Kommentare im Quellcode und in den Tests ergänzen den Code zu einer vollständigen Dokumentation. Kommentare müssen wie Quellcode dem DRY und dem KISS-Prinzip entsprechen. Das bedeutet, es soll nicht dokumentiert werden was der Code macht, denn das wäre eine Verletzung des DRY-Prinzips, sondern warum etwas gemacht wird. Dieses Prinzip des Literate Programming wurde bereits 1992 von Donald E. Knuth beschrieben. Werkzeuge, die aus kommentiertem Quelltext eine Html-Dokumentation erzeugen, sind heutzutage weitverbreitet und können als moderne Version des literate Programming bezeichnet werden. Es ist sinnvoll alle erstellte Diagramme direkt in der erstellten Html-Dokumentation zu verlinken und ebenfalls unter Versionsverwaltung zu stellen.

Dieser Abschnitt behandelt nur Entwicklerdokumentation. Anwenderdokumentation kann nicht aus dem Quelltext generiert werden und muss nach wie vor manuell erstellt werden. Wie das am besten durchzuführen ist hängt stark von der Art des Projektes und der benötigten Form der Dokumentation ab (Gedrucktes Handbuch, Online-Hilfe, usw.). Wie Anwenderdokumentation erstellt werden soll kann deshalb nicht generalisiert werden und muss für jedes Projekt individuell entschieden werden.

Die abschliessende Phase einer UDD-Iteration stellt der Usability Test dar. Dabei testet der Entwickler die neu implementierte Funktion. Dabei ist es Hilfreich die Beschreibung der Funktionalität auf der Storycard als Aufgabe zu betrachten, die erfüllt werden muss.

Sollten hierbei trotz der ausgiebigen Test Fehler gefunden werden, ist umgehend das vorhergegangene Deployment rückgängig zu machen, und die Iteration mit dem Ziel der Fehlerbehebung neu zu durchlaufen. Im Normalfall sollte die Funktionalität gewährleistet sein.

Es wird jedoch oft der Fall eintreten, dass Ideen für die Verbesserung der gerade entwickelten Funktionalität oder einer anderen Funktion des Systems entstehen. Diese werden in Form von Storycards notiert und müssen von der Geschäftsseite beim nächsten Planungsspiel priorisiert werden.

Der Begriff Deployment beschreibt die automatische Verteilung und Auslieferung der entwickelten Software. Im Optimalfall sollte die neu erstellte Funktion im Produktivsystem eingespielt werden. Dazu eignen sich beispielsweise Webanwendungen oder serverbasierte Systeme.

Das bringt den Vorteil, dass den Nutzern der Software Weiterentwicklungen sofort zur Verfügung stehen. Dies birgt jedoch trotz umfangreichen Test ein gewisses Risiko, dass Fehler in eine Produktivversion gelangen. Damit man dieses eingehen kann, muss die Möglichkeit bestehen, ein Deployment jederzeit einfach wieder rückgängig zu machen.

Bei Systemen die nicht serverbasiert arbeiten, oder Anwendungen bei denen ein sofortiges Einspielen der neu entwickelten Funktionen nicht erwünscht ist, sollte man das Deployment zumindest auf einem Testsystem vornehmen, um immer ein funktionierendes System mit der neuesten Softwareversion für Tests und Demonstrationen zur Verfügung zu haben.

Integration bedeutet das Zusammenführen des geänderten Quellcodes mit der Codebasis. Bevor dieser Schritt durchgeführt werden kann müssen alle Tests erfolgreich durchlaufen werden.

Als Werkzeug für die Integration sollte unbedingt eine Versionsverwaltung eingesetzt werden. Es ist ratsam zusätzlich zum Quellcode auch die in der Phase Modellierung eventuell erstellten Diagramme in die Versionsverwaltung eingecheckt werden.

Auch auf Werkzeuge die, automatisch bei jeder Softwareversion die in die Versionsverwaltung eingespielt wird alle Tests durchlaufen und einen Build anstoßen, sollte nicht verzichtet werden. Dadurch können Fehler wie, das vergessene Einchecken einer Datei in die Versionsverwaltung, leicht entdeckt werden.

In der Phase der Programmierung werden die Ergebnisse aus den vorherigen Phasen umgesetzt. Das zuvor gestaltete Userinterface wird implementiert, benötigte Klassen und Methoden geschrieben und Datenbankstrukturen entwickelt.

Es sollte hierbei immer die einfachste funktionierende Lösung implementiert werden (vgl. Das KISS-Prinzip). Die Programmierung ist abgeschlossen wenn alle Test fehlerfrei ausgeführt werden können. Nachdem alle Tests erfolgreich ausgeführt werden können, sollte der neu entwickelte Quellcode einem Refactoring unterzogen werden.

Bevor zur nächsten Phase übergegangen werden kann sollte überprüft werden, dass sowohl die in der vorherigen Phase entwickelten Tests, als auch die in dieser Phase entwickelten Klassen und Methoden ausreichend dokumentiert sind.