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.

Continue reading "URLs kürzen wie ein Pirat"

Serendipity und die neue Twitter API

Twitter hat in letzter Zeit einiges an ihrer API geändert, nichts davon wirklich zum besseren, die API wird vor allem deutlich restriktiver gehandhabt. So muss man sich nun z.B. für einfache Suchen bereits an der API mit OAuth anmelden, weshalb das Seitenleisten Plugin, das eine Twitter Timeline darstellen kann, seit einiger Zeit nicht mehr ging. Garvin hat dafür schnell einen Hotfix released, mit dem diese Funktion zumindest eine Zeit lang ohne OAuth wieder funktionieren kann.

Er hat dafür die API V.1 benutzt, die die alte REST API ablöst, wodurch letztere seit einiger Zeit nicht mehr komplett zugreifbar ist. API V.1 benötigt noch nicht überall ein OAuth Login, aber auch diese wird Anfang des kommenden Jahres zu Gunsten der neueren API 1.1 abgeschaltet. Letztere benötigt dann wie oben angemerkt auch für einfachste Funktionen bereits ein OAuth Login. Oder kurz: Anfang des Jahres werden viele Plugins und Clients nicht mehr funktionieren, wenn sie nicht auf die API V.1.1 angehoben wurden.

Das habe ich jetzt für das Microblogging Plugin und das  OEmbed Plugin erledigt. Beide benutzen nur noch die neue API 1.1. Glücklicher Weise benötigt diese beim OEmbed Zugriff zumindest kein OAuth Login (was auch der OEmbed Idee völlig widersprechen würde), somit muss hier nur ein Update erledigt werden.

Continue reading "Serendipity und die neue Twitter API"

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.

Continue reading "Real Time Web für Server"
tweetbackcheck