Was sind URL Shortener?

Der Sinn und Zweck dieser Angebote ist es schlicht und einfach, eine lange URL - die so nicht oder kaum in das 140 Zeichen Limit von Twitter passen würde - in eine sehr kurze Form umzuwandeln. So kann man z.B. mit dem URL Shortener Urgestein tinyurl.com folgende zugegebenermaßen lange URL http://webmatze.de/wie-manche-url-shortener-daran-scheitern-urls-zu-kurzen/ in diese kurze URL http://tinyurl.com/yep6crr umwandeln. So wurden in diesem Fall 49 der ehemals 75 Zeichen eingespart werden, was einer Ersparnis von über 65% entspricht. Diese neue kürzere URL lässt sich nun auch problemlos in einem Tweet auf Twitter verwenden.

Es geht noch kürzer

Eine Ersparnis von 65% hört sich natürlich sehr gut an und viele neuere URL Shortener würden hier sogar noch mehr Zeichen einsparen können. Da die Beschränkung auf 140 Zeichen bei Twitter nicht viel Spielraum für Inhalt und Links auf andere Seiten lässt, sind viele neuere URL-Kürzer dazu übergegangen auch schon bei der eigenen URL Zeichen einzusparen. So besteht die URL von http://bit.ly/ selbst nur noch aus 14 Zeichen. Das sind immerhin 5 Zeichen weniger als bei http://tinyurl.com/. Und andere Anbieter wie http://ow.ly/ oder http://tr.im/ können hier sogar noch 1 weiteres Zeichen weniger vorweisen.

Woran viele URL Shortener scheitern

Aber bei meinen Recherchen zu den verschiedenen URL Shortener Services ist mir bei allen ein kleines Problem aufgefallen. Sie alle scheitern daran bereits kurze URLs noch weiter zu kürzen. Das mag komisch oder auch sinnlos klingen, aber wenn man den URL Shortenern eine kurze URL wie http://sl.im/ übergibt - hierbei handelt es sich selbst auch um einen URL Shortener - dann bekommt man statt einer noch kürzeren URL eine viel längere heraus!

So gibt mir tinyurl.com hier http://tinyurl.com/ya67oww zurück. Das sind ganze 13 Zeichen mehr als die original URL und somit doppelt so groß! Auch bit.ly verlängert diese URL immerhin auf 19 Zeichen: http://bit.ly/lQUoh. Und ich könnt immer so weiter machen. http://tr.im/ACGS, http://is.gd/3WriH oder http://ow.ly/sCb3 sind alle deutlich länger als das Original!

Hallo? Das sind doch keine URL Shortener, sondern URL Longener! Aber Spaß beiseite. Ich denke die Entwickler dieser Services sollten in solchen Fällen einfach die Original URL zurückgeben. Wo es nichts zu kürzen gibt, muss auch nicht weiter gekürzt werden. Aber abgesehen von diesem kleinem Problem, funktionieren die meisten URL Shortener wirklich super und bieten teilweise weitere Funktionen wie Statistiken zu den einzelnen gekürzten URLs an. Dadurch lässt sich sehr gut nachvollziehen, wie oft, wann und von von wo eine URL aufgerufen wurde. Dieses Feature hat sich für mich auf jeden Fall als sehr praktisch erwiesen.

Vielleicht kann ich deshalb auch ab und zu mit einer im Endeffekt längeren URL leben.

In den Tagen des Social Webs gehört es unter anderem zu den häufigen Aufgaben eines Entwicklers, XML Dokumente zu generieren, oder APIs auf Basis von XML bereitzustellen. News wollen in Form von RSS oder Atom abonniert werden, Inhalte aus anderen Webangeboten über XML in die eigenen Seiten integriert werden.

XML ist also ziemlich wichtig und daher sollte das Erstellen und die Verarbeitung von XML mit einem Framework wie Ruby on Rails auch so einfach und unkompliziert wie möglich erfolgen.

Was ist Google Sitemaps?

Wie dies funktioniert und welche Schritte dafür notwendig sind, werde ich am Beispiel einer Google Sitemap für ein Blog zeigen. Google stellt mit Google Sitemaps eine Methode zur Verfügung, um neue Inhalte aus dynamischen Webseiten noch schneller in den Google Suchindex aufnehmen zu lassen. Dazu können Webseiten eine sitemap.xml Datei zur Verfügung stellen, welche in Form von XML Daten wie URL, Erstell- bzw. Updatedatum und eine Indizierungspriorität zu allen verfügbaren Seiten - in unserem Fall sind dies die Blogeinträge - enthalten kann.

Rails Generator hilft uns

Bei großen dynamischen Seiten ist es natürlich aufwendig, diese XML Datei immer von Hand zu pflegen, darum wollen wir diese mit den Mitteln von Ruby on Rails automatisch generieren lassen.
Überlegen wir doch erstmal, was wir alles für die geforderte Aufgabe benötigen. Wir brauchen einen Sitemap Controller mit einer index Action, welche wir aufrufen können und die dann schließlich das XML generiert. Also sollten wir zuerst diesen neuen Controller generieren lassen. Dies ist in Ruby on Rails mehr als einfach:

ruby script/generate controller Sitemap index

Dieser Komandozeilenaufruf nimmt uns diese Aufgabe ab. Der Rails Generator legt daraufhin mehrere Dateien an. Unter anderem den Controller sitemap_controller.rb mit der Action index und den View index.html.erb.

     exists  app/controllers/
exists  app/helpers/
create  app/views/sitemap
exists  test/functional/
create  app/controllers/sitemap_controller.rb
create  test/functional/sitemap_controller_test.rb
create  app/helpers/sitemap_helper.rb
create  app/views/sitemap/index.html.erb

Der Controller

Im nächsten Schritt holen wir uns in der bereits für uns angelegten index Action eine Liste mit allen vorhandenen Blogeinträgen und sagen Rails, dass das Ergebnis als XML gerendert werden soll.

class SitemapController < ApplicationController

def index
@articles = BlogArticle.find(:all, :order => 'created_on DESC, updated_on DESC')
respond_to do |format|
format.xml { }
end
end

end

Wie man sehen kann, sortieren wir die gefundenen Blogeinträge absteigend nach Erstellungs- und Bearbeitungsdatum. So ist sichergestellt, dass die aktuellsten Einträge in der XML Datei später immer am Anfang stehen.

Mit Rails XMLBuilder ist XML so einfach wie noch nie

Wie im ersten Schritt zu sehen, hat Rails für uns mit der index.hmtl.erb auch schon die Viewdatei für die index Action erstellt. Da wir jedoch kein HTML sondern XML ausgeben wollen, benennen wir diese Datei in index.xml.builder um.

Diese Umbenennung hat zwei Effekte. Rails wird auf diese Datei automatisch zurückgreifen, wenn XML gerendert werden soll und die Endung .builder teilt Rails mit, dass der Inhalt dieser Datei Anweisungen für den Rails eigenen XML Builder enthält. Mit diesem Builder lassen sich schnell komplexe XML Dateien erstellen, wie wir am folgenden Beispiel sehen werden.

xml.instruct!

xml.urlset "xmlns" => "http://www.google.com/schemas/sitemap/0.84" do
xml.url do
xml.loc         "http://www.name-der-seite.de/"
xml.lastmod     w3c_date(Time.now)
xml.changefreq  "always"
end

@articles.each do |article|
xml.url do
xml.loc         url_for(:only_path => false, :controller => 'blog', :action => 'show', :id => article)
xml.lastmod     w3c_date(article.created_on)
xml.changefreq  "weekly"
xml.priority    0.8
end
end

end

Dieser Code ist so ziemlich selbsterklärend. Es wird über verschiedene xml Anweisungen die Struktur der sitemap.xml erzeugt und über alle BlogArticles iteriert.

Eine Hilfe für das Datumsformat

Zur Ausgabe des Datums im richtigen Format haben wir die Methode w3c_date() im sitemap_helper.rb definiert.

module SitemapHelper

def w3c_date(date)
date.utc.strftime("%Y-%m-%dT%H:%M:%S+00:00")
end

end

Fast fertig

Damit wir diese Action nun auch über die URL http://www.name-der-seite.de/sitemap.xml aufrufen können, werden wir in der Datei routes.rb noch ein entsprechendes Mapping anlegen.

map.connect "sitemap.xml", :controller => "sitemap", :action => "index"

Nun steht dem Aufruf durch Google und der anschließenden erfolgreichen Indizierung unserer gesamten Blogbeiträge nichts mehr im Weg.

Abschließend kann man sagen, dass XML mit Ruby on Rails wirklich nicht schwer ist. Wenn man den gesamten Aufwand betrachtet, so konnten wir die geforderte Funktionalität in 5 bis 10 Minuten umsetzen. Wenn das nicht effektiv ist, was denn dann? :o)

Wenn man von aktuellen Trends in der Web 2.0 Szene reden will, dann sollte ein Trend unbedingt enthalten sein - Live Shopping. Wer die bekanntesten Shopping Startups der US Szene beobachtet, dem wird vor allem das Unternehmen woot.com aufgefallen sein. Woot stellt seinen Nutzern jeden Tag ein bestimmtes Produkt zu einem sehr niedrigem Angebotspreis vor. Das Angebot ist limitiert und läuft exakt einen Tag lang. Wenn der Vorrat leer oder die Zeit abgelaufen ist, kann man das Produkt nicht mehr bestellen und muss auf das Angebot des nächsten Tages warten.

Live Shopping setzt sich durch

Dieses Shop-Konzept ist in den USA dermaßen erfolgreich, dass sich auch bei uns einige Anbieter der Idee angenommen und eigene "Woot Clones" aufgesetzt haben. Am erfolgreichsten hat guut.de das Konzept umgesetzt und kann auf stetig wachsende Umsatzzahlen verweisen. Aber auch preisbock.de und schutzgeld.de erfreuen sich einer immer größer werdenden Fangemeinschaft.

Mittlerweile ist das Angebot an deutschen Live Shopping Portalen so groß geworden, dass es schwierig wird, jeden Tag auf dem Laufenden über die aktuell angebotenen Produkte zu bleiben. Hier kommt mit myliveshopping.de ein neuer Anbieter ins Spiel, welcher nicht etwa ebenfalls Produkte anbietet, sondern vielmehr einen umfassenden Überblick über alle Live Shopping Anbieter und deren aktuelle Angebote bietet. Damit ist myliveshopping.de der erste "Deal of the Day" Tracker Deutschlands.

Da ich selbst am Anfang allein auf guut.de aufmerksam geworden war und erst nach einer Weile auf die vielen anderen Live Shopping Portale stieß, kommt für mich das Angebot von myliveshopping.de genau zur rechten Zeit. Habe ich zuletzt immer nur das aktuelle Angebot des Tages von guut.de beobachtet, indem ich die Seite in einem Tab meines Firefox Browsers geöffnet ließ, kann ich nun die Angebote aller Live Shopping Portale auf einmal beobachten.

Alles auf einem Blick

myliveshopping.de ist sehr übersichtlich aufgebaut. Auf der Startseite sind untereinander immer die gerade laufenden Angebote der einzelnen Anbieter aufgelistet, so dass man sich schnell einen Überblick über die interessanteren Angebote verschaffen kann. Die Angebote werden hier mit Bild und Text vorgestellt und natürlich fehlt auch der jeweilige Preis an dieser Stelle nicht. Im oberen Bereich wird dabei jeden Tag das interessanteste der Produkte gesondert vorgestellt.

Mit einem Klick gelangt man dann schnell zur detaillierten Beschreibung des gewählten Produktes. Hier bindet myliveshopping.de die Angebotsseite des jeweiligen Anbieters über ein Frame ein. Die einzelnen Produkte können von den Besuchern mit insgesamt bis zu fünf Sternen bewertet werden. Außerdem können zu jedem Live Shopping Portal detaillierte Reviews abgegeben werden. Auf der Review Seite erfährt man zudem mehr über die Konditionen des Anbieters, wie z.B. Lieferdauer, Zahlungsarten, Angebotsdauer usw.

Hat man sich für ein Produkt entschieden, kann man dieses sofort kaufen. Der Bestell- und Zahlungsvorgang läuft jedoch nicht über myliveshopping.de ab, sondern wird über das jeweilige Live Shopping Portal abgewickelt. Will man also ein Produkt kaufen, muss man sich bei dem entsprechenden Anbieter anmelden und kann dann den Kauf abschließen.

Fazit

Wenn man sich für das Live Shopping Angebot interessiert und immer auf dem Laufenden bleiben möchte, kommt man heute um myliveshopping.de nicht herum. Nie war es einfacher alle Angebote auf einem Blick überschauen zu können.

Jeder dem das "Web 2.0" ein Begriff ist, sollte auch einen seiner bekanntesten und einflussreichsten Vertreter kennen. Damit meine ich Digg.com, eine Seite auf der deren Mitglieder beliebige Links zu anderen Seiten mit möglicherweise für andere Nutzer interessanten Inhalten veröffentlichen können. Der "Mitmach-Faktor" dabei ist, dass nun alle anderen Mitglieder selbst bewerten können, ob ihnen die verlinkten Seiten gefallen. Dies geschieht indem sie der verlinkten Seite ein "Digg" geben, also eine Art "Daumen hoch". Je mehr Diggs nun solch ein Link bekommt, um so weiter oben in der Liste erscheint dieser. Die beliebtesten erscheinen schließlich auf der Startseite von Digg.com. Links die es bis dorthin schaffen ziehen eine riesige Menge an Aufmerksamkeit auf sich. Und mit Riesig meine ich so viel, dass die verlinkten Seiten häufig unter der Last des Besucheransturms in die Knie gehen, weil deren Server überlastet werden.

Digg.com hat also einen sehr großen Einfluss auf das Web und ist ein Paradebeispiel für "Web 2.0" Seiten, deren Inhalte durch eine große Nutzerbasis erschaffen und bestimmt werden. Aber gerade diese Demokratie kann jetzt möglicherweise den Niedergang von Digg.com bedeuten.

Was ist geschehen? Nun, alles fing damit an, dass ein Blogger aus Ecuador einen aus 32 Zeichenpaaren bestehenden Code zum Knacken des Kopierschutzes von HD-DVDs und Blu-Ray-Discs in seinem Blog veröffentlichte. Einen Code, welchen die Filmindustrie schon seit Wochen mit Unterlassungserklärungen versucht aus dem Web zu klagen. Überzeugt von seiner Geschichte setzte er den Link zu seiner Seite auch bei Digg.com rein. Es dauerte nicht lange und die Geschichte erhielt die ersten "Diggs". Mit der Zeit wurden es immer mehr und die Seite stand schließlich auf der Startseite von Digg. Doch plötzlich wurde die Geschichte von Digg.com gelöscht und der Account des Bloggers gesperrt. Die Macher von Digg waren sich der Copyright Problematik bewusst, schließlich war vorher auch schon Google von den Anwälten der Filmindustrie abgemahnt worden und musste alle Referenzen auf den Code löschen.

Hier hätte unsere kleine Geschichte nun vorbei sein können, aber an dieser Stelle fingen nun die Nutzer von Digg.com an zu rebellieren. Sie waren ganz und gar nicht damit einverstanden, dass die Geschichte einfach gelöscht wurde. Zumal dies auch den immer wieder gepredigten Grundsatz von Digg.com widersprach. "Digg ist digitale Medien-Demokratie." Und da reagieren die Nutzer schon mal sehr empfindlich, wenn auf einmal Inhalte zensiert bzw. ganz gelöscht werden. Also machten sich einige Digg-Mitglieder nun daran, neue Stories über den HD-DVD Code in Digg einzustellen, und die Digg-Moderatoren versuchten nach und nach alle diese neuen Stories ebenfalls wieder zu löschen. Außerdem wurden immer mehr dieser Mitglieder gesperrt. Doch das hielt sie nicht davon ab immer wieder neue Stories einzustellen. Dabei bewiesen viele hohen Einfallsreichtum in der Betitelung dieser Geschichten. Andere bauten den Code in Grafiken ein oder sogar in Videos auf Youtube.com. Dies ging dann soweit, dass die Startseite von Digg nur noch mit Stories über dieses eine Thema gefüllt war.

An diesem Punkt gaben die Macher von Digg schließlich auf. Kevin Rose, der Erfinder von Digg, meldete sich im Blog: "Jetzt, nach Hunderten von Geschichten und Tausenden von Kommentaren, habt ihr es klar gemacht: Ihr wollt Digg lieber kämpfend untergehen als vor einer größeren Firma einknicken sehen." Und kommt zu dem Schluss: "Wir werden ab sofort Geschichten und Kommentare mit dem Code nicht mehr löschen und uns mit allen möglichen Konsequenzen auseinandersetzen."

Damit liegt die Zukunft von Digg nicht mehr bei Rose, sondern bei den Nutzern selbst. Sollte Digg im Rechtsstreit mit der Filmindustrie unterliegen, könnte dies möglicherweise auch das Ende von Digg selbst bedeuten. So sagt es auch Rose in seinem Blog: "Wenn wir verlieren - was soll's - dann sterben wir wenigstens kämpfend." Richtig. Doch wichtiger noch scheint, dass der Kampf nicht mit den eigenen Mitgliedern, sondern mit der Filmindustrie ausgefochten wird. Denn den Kampf mit den Mitgliedern kann man vielleicht gewinnen, aber höchstwahrscheinlich mit der Konsequenz, dass viele der Mitglieder dann Digg den Rücken zukehren würden. Und dies sollte nicht im Interesse von Rose sein.

Ich kann mir vorstellen, dass nun viele andere Betreiber von "Web 2.0" Seiten das weitere Geschehen sehr genau beobachten werden. Denn jede Seite mit einer solch großen Nutzerbasis und mit von Nutzern generierten Inhalten kann sehr schnell vor dem gleichen Problem stehen. Aber eine Lehre sollte schon jetzt jeder daraus ziehen - bekämpfe nicht deine eigenen Nutzer!

Ich melde mich gerne überall extra an. Das erspart mir, dass ich über die Grenzen einer Website/eines Anbieters hinweg gescored werden kann. Ich weiß, in Consumer-Märkten können sich Marketing-Leute nichts besseres vorstellen, als Bürger finde ich die Vorstellung jedoch eher Furcht erregend. Denn wo die Daten am Ende landen oder ob sie vor fremden Zugriffen wirklich sicher sind, kann irgendwann relevant werden.

Dem kann ich auch nur zustimmen. Einerseits wäre es schon schön einen zentralen Dienst zu haben über den man sich überall anmelden kann. Nur der Bequemlichkeit wegen. Am besten mit einen Cookie welcher einem auch noch das Eingeben der Benutzerdaten erspart. Dies ist schön bei Google zu sehen, wo man sich nur einmal anmelden muß, z.B. bei Google Mail, und schon kann man auch auf den Google Calendar zugreifen. Warum dann nicht auch gleich automatisch bei del.icio.us angebmeldet sein?
Andererseits macht es mir jetzt schon Sorgen, dass Google anscheinend alle meine Bewegungen im Netz mitverfolgen kann. Bin ich bei Google angemeldet, kann Google auch ganz leicht sehen, welche Anwendungen ich von Google verwende. Das mitgespeichert wird, nach welchen Begriffen ich gesucht habe ist ja schon länger bekannt. Das nennt sich dann einfach "Search History". Aber wenn man bedenkt, dass in fast jeder Seite heute Google AdSense Werbung eingebunden ist, was sollte Google davon abhalten zu speichern, von welcher IP Adresse diese Werbungen auf welcher Seite aufgerufen wurden? Und da ich bei Google angemeldet bin, kann man der IP Adresse auch schnell einen Namen zuordnen. Und schon weiß Google ganz genau wofür ich mich interessiere, was ich kaufe und vieles mehr.
Nein, da stimme ich Torsten Herrmann zu, auch ich melde mich lieber überall selbst an. Soviel Zeit muß sein.

naja, zumindest auf diesem hier generierten Schriftzug...

Ein Vergleich mit der USA bringt jedoch hervor, dass dort schon seit Mitte 2004 nach dem gleichen Suchbegriff gesucht wird.

Läßt sich aus diesem Ergebnis schließen, dass Deutschland im Bereich Internettechnologien etwa eineinhalb Jahre hinter der USA liegt? Vielleicht findet Ihr ja noch weitere Beweise dafür.