Skip to content

URLs kürzen wie ein Pirat

Ich benutze seit kurzem einen neuen URL Kürzer. Ein neuer URL Kürzer? Gibt es da nicht schon reichlich von? Na klar, nur bin ich bei diesem inzwischen involviert und mag einige Features an dem Kürzer sehr. Angefangen hatte alles mit einem Tweet:

Da ich mal wieder Lust hatte, an einer eigenen Android App zu schrauben, meldete ich mich. Das Resultat gibt es jetzt in Google Play.

Besonderheiten des pirat.ly Kürzers

Der pirat.ly Service wurde von einem Mitglied der Piratenpartei in Wiesbaden aufgesetzt und hat deshalb schon mal eine recht besondere URL. Der Service wurde ursprünglich für Piraten erstellt, kann aber auch von allen anderen frei benutzt werden. Ähnlich Services wie bit.ly kann man sich bei dem Service kostenlos registrieren, wodurch man ein API Token bekommt. Wenn man dieses benutzt, kann man sich die Klick Raten seiner Links ansehen, sowie wann diese URL das letzte Mal benutzt wurde.

Was mir persönlich sehr gut gefällt ist seine enge Verzahnung mit QR Codes. Für jeden pirat.ly Link wird ein QR Code hinterlegt, den man z.B. am mobilen Gerät seinen Freunden zeigen kann, die dann den Link einfach scannen können anstatt ihn abschreiben zu müssen.

"URLs kürzen wie ein Pirat" vollständig lesen

Real Time Web für Server

Das Problem

Seit dem ich für mein Blog die Wordpress App benutze, um über neue Kommentare informiert zu werden, nervt mich ein Problem: Die App muss regelmäßig abfragen, ob etwas neues im Blog vorhanden ist. Will man zeitnah informiert werden, muss man die Frequenz der Abfrage relativ hoch stellen. Das hat allerdings zur Folge, dass der Client zum großen Teil unnötige Abfragen produziert, die sowohl beim Server wie beim Client ziemlich sinnlos Ressourcen (Akku am Client, Traffic am Server) verbrauchen. Erschwerend kommt hinzu, dass die Wordpress App ständig aufhört, regelmäßig abzufragen, und für diesen Anwendungsfall für mich nutzlos wird.

Das gleiche Problem hatte ich auch bei Superious, meinem Posterous Client für Android. Hier ist es richtig schwierig, eine passende Abfrage Frequenz einzustellen. Bei Posterous kommt tagelang nichts (in denen der Client erfolglos nach neuem sucht) und dann entwickelt sich an manchen Tagen eine Diskussion, die man zeitnah verfolgen möchte. Die optimale Abfrage Frequenz ist also unterschiedlich.

Google hat dazu mal in einem Video ein gutes Metapher gefunden: Es ist wie eine Autofahrt mit kleinen Kindern, auf der diese ständig fragen: "Sind wir schon da? Sind wir schon da?!" Die Eltern würden sich wünschen, dass die Kinder mit der sinnlosen Fragerei aufhören würden, und statt dessen darauf warten würden, dass der Fahrer sagt: "JETZT sind wir da."

Beispiel RSS

Das Web funktioniert immer noch in vielen Bereichen wie die beschriebene Autofahrt. Ein prominentes und gut zu verstehendes Beispiel sind die RSS Feeds von Blogs. Blogs veröffentlichen diese mit den aktuell verfügbaren Artikeln. Clients (Feedreader) lesen die Feeds und bereiten sie auf. Dabei müssen die Reader mit einer intelligenten Frequenz beim Blog die RSS Feeds auslesen und mit vorherigen Aufrufen vergleichen, ob es etwas neues gibt.

Man würde sich wünschen, dass das anders laufen würde: Der Server (das Blog, Posterous, ..) meldet in dem Moment, da er etwas neues hat, an seine Clients: "JETZT habe ich etwas neues." Auf diese Weise würde der Server nicht mehr mit ständigen Anfragen konfrontiert, der Client könnte sich mit anderem beschäftigen (oder in den Sparmodus wechseln), trotzdem würden Änderungen sofort am Client bekannt werden, wenn sie entstehen. Im Gegensatz zu der herkömmlichen Technik, die man Pull nennt (der Client "zieht" sich Informationen), wäre dies eine Push Technik (der Server "drückt" Informationen, wenn sie vorhanden sind).

Für Server zu Server Kommunikation gibt es so etwas schon seit längerem: z.B. Pubsubhubbub.

"Real Time Web für Server" vollständig lesen

Twitter sperrt seine Inhalte

Twitter übernimmt immer mehr die Kontrolle über seinen Kontent, um diesen bewerben zu können. Vor kurzem wurde die Freiheit der Clients, die Twitter (meiner Meinung nach) u.a. so erfolgreich gemacht haben, stark beschnitten: Es gibt inzwischen genaue Vorgaben, wie der Inhalt von Twitter dargestellt werden muss. Wer sich daran nicht hält, dem droht die Abkopplung von der Twitter API.

Jetzt trifft es auch "Meta Clients" wie IFTTT, die am 27.9 das Weiterleiten von Twitter Inhalten und Events an andere Services abschalten werden, um mit den neuen Richtlinien konform zu gehen. Dabei sind die IFTTT Kanäle, die Inhalte an Twitter liefern, vorerst nicht betroffen.

Warum Twitter diese Unterscheidung macht, ist klar: Sie wollen ihren Content unter Kontrolle behalten und mit ihm durch Werbung Geld verdienen. Das geht nicht, wenn Clients Inhalte beliebig darstellen und filtern oder Services wie IFTTT den Inhalt aufbereitet in andere Bereiche verteilt. Der Eingang von Twitter bleibt vorerst davon nicht betroffen. Auch hier liegt der Grund auf der Hand: Twitter kann viel Werbung nur mit viel Inhalt machen, somit sind die Eingänge noch so offen, wie möglich.

"Twitter sperrt seine Inhalte" vollständig lesen
tweetbackcheck