Ruby on Rails

Since it first appeared in July 2004, Ruby on Rails has revolutionized the process of developing web applications. It has enabled web developers to become much faster and more efficient, al lowing for quicker application development a critical advantage in these days of web time.
(Orsini 2007, S.1)

 

Ruby on Rails ist ein in Ruby programmiertes Framework für die Entwicklung von Webapplikationen. Es wurde von David Heinemeier Hansson entwickelt und 2004 der Öffentlichkeit vorgestellt. Das Framework folgt dem Model-View-Controller Architekturmuster, bei dem das Softwaresystem in Datenhaltungsschicht (Model), Präsentationsschicht (View) und Programmsteuerung (Controller) aufgeteilt wird.

Ruby on Rails macht von der Möglichkeit der Metaprogrammierung gebrauch um Methoden zu definieren, die wie Erweiterungen der Ruby Syntax wirken. Es folgt dem Prinzip Don’t Repeat Yourself und stellt Konvention über Konfiguration.

Besonders hervorzuheben ist das Modul Active Record, das eine objektrelationale Abbildung der Datenbank nach dem von Martin Fowler, in Patterns of Enterprise Application Architecture, vorgestellten Active Record Designpattern bereitstellt. In Agile Web Development with Rails wird Ruby on Rails in allen Details beschrieben.

Journizers Log – Das Online Reisemagazin!

Das Journizers Log ist das Online Reisemagazin der Reisecommunity Journizer. Jeden Monat gibts hier Reisegeschichte eines Journizers und nützliche Reisetipps zu lesen. Wir haben dem Journizers Log eine eigene Webseite spendiert. Passend dazu gibts einen Aufruf an alle Reiseschriftsteller und solche die es werden wollen:

Wir wollen Deine Reisegeschichten!

Wir sind immer auf der Suche nach Geheimtipps, lustigen Erlebnissen und Reiseabenteuern – und natürlich nach spannenden Reiseberichten.
Pack Dir einen Griffel und fange an zu schreiben…

Programmierung eines Widgets mit der Netvibes Api

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:
 

style=“width:250px;margin-left:auto; margin-right:auto;“> Loading the Journizer widget

 

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.

UDD – Bei jeder Iteration

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.

Aussagekräftige Html-Titel

Jede Html-Datei muss einen Titel enthalten. Der im Html-Kopf notiert ist und für folgende Dinge verwendet wird:

  • Der Titel wird bei der Darstellung der Datei im Web-Browser in der Titelzeile des Browserfensters und in Karteireitern angezeigt.
  • Der Titel wird von Webbrowsern beim Speichern von Lesezeichen verwendet.
  • Der Titel wird im Verlauf der besuchten Seiten in Webbrowsern angezeigt.
  • Der Titel wird bei der Indizierung von Webseiten durch Suchmaschinen als wichtiges Merkmal verwendet.

Somit sollte der Titel möglichst exakt dem Inhalt der Seite entsprechen. Das wirkt sich positiv auf die Usability der Seitennavigation und beim Setzen von Lesezeichen im Webbrowser aus.

Ein Html-Titel muss im Html-Kopf einer Datei definiert werden. Der Html-Kopf sollte aus Gründen der Wartbarkeit nur an einer Stelle im Projekt notiert werden und alle Dateien sollten diesen zentral gehaltenen Html-Kopf inkludieren. Da Titel einer Html-Datei möglichst dem Inhalt der Seite entsprechen sollte, muss dieser im Idealfall für jede einzelne Seite angepasst werden. Den Html-Kopf in einzelne Seiten der Darstellungschicht zu kopieren würde jedoch dem DRY-Prinzip widersprechen.

Ein Ausweg besteht darin, im zentral gehaltenen Html-Kopf eine Funktion zu definieren, die das Titel-Element generiert und dessen Inhalte als Parameter von jeder Seite der Darstellungschicht übergeben werden. In der Darstellungschicht kann dieser Methodenaufruf gleichzeitig als Html-Überschrift verwendet werden die bei den meisten Seiten dem Html-Titel entspricht.

Patrick Crowley hat mit Headliner ein Rails Plugin geschrieben das genau das macht. Es ist wirklich einfach zu benutzen.

Nach der Installation über:

script/plugin install http://the.railsi.st/svn/repo/plugins/headliner/

Muss eine zentrale Konfiguration des Plugins in der Layout Datei vorgenommen werden:


< %= title :site => "journizer.com", :separator => "-",
:lowercase => true, :reverse => true %>

In den einzelnen Views kann der Html-Titel jetzt mit:

< %=t "My page title" %>

gesetzt werden.

Webverzeichnis 2.0

In der guten alten Zeit™ als Suchmaschinen lediglich dazu geeignet waren zu suchen, nicht aber um etwas zu finden, haben wir uns durch Webkataloge gehangelt. Igor hat mit seinem CatalogR diese Tradition wieder aufleben lassen. Er hat es sich zur Aufgabe gemacht das deutschsprachige Web2.0 zu katalogisieren und Journizer darin aufgenommen. Vielen Dank dafür!


CatalogR.info | Das deutschsprachige Web 2.0 Webkatalog