Warum tut Gesine Schwan sich das eigentlich (nochmal) an? Sie wird hier eindeutig aus taktischen Gründen zum Kaper gemacht, ihre Kandidatur hat so gut wie keine Chance. Falls sie wider erwarten doch eine halbwegs realistische Chance hätte, kann man so gut wie sicher sein, daß ihr die SPD in ihrer gegenwärtigen Zusammensetzung dann in den Rücken fallen würde.
In letzter Zeit wird Twitter recht viel abgewatscht, weil der Dienst ziemlich instabil läuft. Das ist zwar weniger wichtig, solange man “nur” private Statements wie “Bin verkatert – erstmal’n Käffchen” schreibt, aber der Dienst wird zunehmend auch für ernsthaftere Anwendungen genutzt. Zum Beispiel für Terminhinweise von Veranstaltern oder sonstige Veröffentlichungen.
Kurz: Twitter hat alle Hände voll zu tun, den Dienst stabil und skalierbar zu machen. Von Außenstehenden wurde viel über die Ursachen der Probleme spekuliert. Die beliebtesten Vermutungen: Ruby on Rails skaliert nicht richtig und der Hoster bekommt Last und Traffic nicht in den Griff. Auf dem Entwicklerblog stellt Twitter mit dem Artikel “Twittering About Architecture” nun klar, daß beides nicht die Ursachen sind, sondern grundlegende Fragen der Softwarearchitektur gelöst werden müssen. Zudem ist die Entwicklungsabteilung personell unterbesetzt.
Eine detaillierte Beschreibung der komplexen technischen Herausforderungen für einen Microblogging-Dienst hat Eran Hammer-Lahav in einer kleinen Artikelserie “Scaling a Microblogging Service” beschrieben. Er sah sich bei seinem eigenen Start-up Nouncer mit ähnlichen Herausforderungen konfrontiert und ist daher kompetent. Er unterteilt den Dienst unabhängig von der jeweiligen Implementierung in zwei Bereiche: delivery und retrieval.
Delivery
Hereinkommende Nachrichten zu nehmen und per Instant Message, SMS oder Email an diejenigen weiterzuverteilen, die Follower sind, ist zwar nicht völlig trivial, aber dennoch vergleichweise einfach und es lässt sich leicht skalieren.
Retrieval
Das Problem und die Komplexität steckt in der Abfrage. Hammer-Lahav schreibt dazu:
“Unlike webmail services where refreshing a user’s inbox only queries a very simple data set (is there anything new in MY inbox?), refreshing a user’s home page on Twitter queries a much more complex data set (are there any new updates in ALL my friends’ pages?) and the nature of the service means that the ratio of reads to writes is significantly different from most other web services.“
Eigentlich sind die Abfragen ja noch komplexer, etwa “Gib mir die letzten 20 Nachrichten von allem meinen Kontakten die nicht gesperrt sind und die mich nicht gesperrt haben, sowie alle privaten Nachrichten an mich, absteigend sortiert nach Uhrzeit”. Das funktioniert tadellos, sonlange es nur einige tausend User und einige -zig oder hunderttausend Nachrichten handelt. Die große Menge ist das Problem: partitionierte Datenbanken, was und wie ist zu indizieren, was kann gecached werden etc.
Der Autor vertritt weiterhin die Meinung, daß ein Push-Service mit Inboxen ähnlich wie E-Mail das Problem genausowenig löst, wie ein (in letzter Zeit ja häufig diskutierter) verteilter Service; ja im Gegenteil die Probleme dann nur umso größer würden. Um das zu verdeutlichen entwirft er ein Szenario, in dem 3 User bei verschiedenen Providern (twitter, pownce und Jaiku) sind.
Wirklich interessant: Das nämlich genau das Szenario, für das ich seit kurzem ein simples Push-Protokoll entwerfe. Der Autor kommt auch tatsächlich zu den selben Punkten wie ich, z.B. echte (lokale) Accounts und virtuelle (remote) Accounts. Allerdings bewerte ich sie etwas anders.
Richtig ist: Bei einer zentralen Lösung hat twitter mit einigen Millionen Usern das Skalierungsproblem. Bei einer dezentralen Lösung hat ein Service mit einigen Millionen Usern immer noch dasselbe Skalierungsproblem plus noch einigen anderen Fallstricken, weil er von (vielen) externen Services abhängt.
Aber: Das Problem wird in der Praxis kaum noch auftauchen, wenn die meisten User auf kleineren System sind oder sogar einen eigenen Server betreiben, wie es heute bei E-Mail der Fall ist. Es interessiert mich einfach nicht, wenn Yahoo, GMX, MSN oder wer auch immer ein dickes Problem mit seinen Mailservern hat – ich bin trotzdem per Mail erreichbar. Twittern kann ich aber nur, wenn twitter funktioniert.
Bereits gestern hatte ich bei einem Test herausgefunden, daß ein Fotoupload per GPRS wie zu erwarten langsam ist: ca. 800KB in 2:50 min. Was nicht zu erwarten war, ist daß der Upload eines ähnlich großen Fotos per UMTS sogar noch ein bischen länger dauerte, nämlich 3:15 min.
Die Umstände gestern waren “real-life”. Das erste Bild habe ich im Berliner Hauptbahnhof fotografiert und per GPRS auf das neue zzap hochgeladen. Das zweite Bild habe ich in der Hamburger Speicherstadt fotografiert und per UMTS hochgeladen. Denkbar wäre, daß z.B. in der Hamburger City die UMTS-Funkzellen voll ausgelastet waren oder die beiden Standorte sonst aus irgendeinem Grund nicht vergleichbar waren.
Deshalb habe ich heute mittag bei mir zuhause einen zweiten Vergleich unternommen. Diesmal habe ich zweimal dasselbe Bild (ca. 410KB) genommen und meinen Standort nicht geändert. In meiner Wohnung habe ich sowohl im GSM-Netz, als auch im UMTS-Netz vollen Empfang. Doch auch diesmal ergab sich das gleiche Bild: 410KB upload per GRPS in 1:50 min und per UMTS in 2:15 min.
Was soll das?
Man kann es kaum besser auf den Punkt bringen (Habe jetzt noch Tränen in den Augen).
Die neue Version von zzap schreitet in der Entwicklung voran. Seit gestern kann man per Handy nicht nur Kurznachrichten absetzen, sondern diese auch noch mit einem Foto versehen.
Positiv
Es klappt. Die Bilder kommen an und werden automatisch für Web und verschiedene Handytypen angepasst. Auch die Ausgabe im Browser oder auf dem Handy – alles funktioniert ganz einwandfrei.
Negativ
So ein Upload dauert. Heute morgen auf dem Weg zur Arbeit habe ich zum Vergleich zwei Nachrichten mit Bild verschickt. Dabei sollte ich erwähnen, daß ich das hervorragende SonyEricsson K770i mit einer 3.2 Megapixel Kamera benutze. Die Bilder sind klasse – aber eben auch eingermaßen groß: zwischen 750KB und 850KB. Das erste Bild habe ich per GPRS verschickt. Das hat einschläfernde 2:50min gedauert. Das zweite Bild habe ich per UMTS verschickt und nicht schlecht gestaunt. 3:15min.
“Was zum Geier…?“
Wozu soll ich eigentlich UMTS nutzen? WAP-Seiten sind zu klein um von der höhreren Downloadgeschwindigkeit zu profitieren und der Upstream war ja wohl ein schlechter Scherz. Der einzige Unterschied scheint zu sein, daß mit UMTS der Akku nur 1/3 der Laufzeit bringt. Grrrr…
Ich werde das morgen wiederholen um zu überprüfen, ob es sich nicht um einen Ausreisser wegen Zellenüberlastung oder so was handelte.
Ach ja – wenn ich schonmal am Meckern bin (scheint mein natürlicher Aggregatzustand zu sein): Das Handy ist wirklich klasse – aber warum muss ich die Fotos erst von “Album” nach “Bilder” verschieben, bevor ich sie hochladen kann? Daß eine simple Bildbearbeitung eingebaut ist, ist ja eigentlich auch ganz nett – aber warum kann ich damit zwar sinnlose Filter auf das Foto anwenden, aber nicht die Bildgröße ändern?
Naja, auf 1000 verschiedene Handies kommen vermutlich mindesten 3000 unverständliche Macken. Da wird man sowieso nicht alles abfangen können.
“Seems that I was busy, doin’ something close to nothing”
Prince, Raspberry Beret
Passt heute genau auf mich. Mache nur Blödsinn. Lange (lange!) schlafen, rumtrödeln, kurz in den Supermarkt springen und dann doch die Hälfte vergessen, das Auto waschen kurz bevor es so richtig fett regnet, rumbloggen, 2 Stunden lang Followerlists auf twitter durchscannen und gucken, wen man so kennt. Sind doch immerhin so einige dabei.
Was mir bei letzterem auffiel: Die Beschränkung auf extrem kurze Texte verführt die Leute zu allerhand Wortspielchen, Manche sind platt viele lustig und einige geradezu grenzgenial.
Ich verstehe die gritzegrauen Kulturpessimisten in den alten Medien überhaupt nicht, die uns immer einreden wollen, daß “die Jugend” der deutschen Sprache nicht mehr mächtig wäre, bloß weil sie keine langweiligen Zeitungen mehr lesen.
**kopfschüttel**
Da ich mich heute mit der Fokussierung auf Kernfunktionalität beschäftige, passt das hier thematisch gerade ganz gut:
Wer schreibt, weiß daß man dazu sehr konzentiert sein muss. Man wird aber heute sehr leicht abgelenkt und braucht dann oft ziemlich lange, um “den Fluss” wiederzufinden. So kann eine kurze Ablenkung von vielleicht 20 Sekunden, leicht mal 15 Minuten Arbeit kosten.
Damals(TM) war bekanntlich alles besser. ;-)
Ich meine nicht das Damals, als wir noch keine E-Mails und aufpoppende Instant Messenger und wöchentliche 150MB-Pflicht Updates hatten. Ich meine das Damals als ein Autor schrieb und wenn das geschreibene tatsächlich gedruckt werden sollte, gab man das Geschriebene einem Setzer. Der kümmerte sich dann um Layout, korrekte Satzzeichen, Zeilen- und Seitenumbrüche, “Hurenkinder”, “Schusterjungen” und dergleichen mehr. Der eigentliche Druck wurde abschließend selbstverständlich von einem Drucker ausgeführt – also dem Menschen an der Druckmaschine.
Im Umkehrschluss bedeutet das, daß sich der Autor – anders als heute – eben nicht um die Form zu kümmern brauchte, sondern sich auf den Inhalt konzentrieren konnte. Es gab eine klare Arbeitsteilung:
schreiben, setzen, drucken.
Offensichtlich gibt es zunehmend mehr Autoren, die die ältere Arbeitsweise bevorzugen. Neulich brachte der Spiegel einen Artikel mit dem Titel “Keine Angst vor LaTeX” (sprich “La-Tech”). LaTeX ist ein Programm, daß das macht, was früher ein Setzer machte. Man übergibt dem Programm den Text, stellt Formatierungsregeln auf und bekommt eine hochwertige, fertig gesetzte Druckdatei, die kein normales Textverarbeitungsprogramm in vergleichbarer Qualität liefert.
Mit LaTeX kann man zwar wundervoll setzen, allerdings weder drucken, noch schreiben. Man druckt, indem man die erzeugte Postscript-Druckdatei an einen Drucker (das Gerät, nicht der Mensch) schickt, der dieses Format versteht.
Jetzt fehlt noch die Eingabeseite. Ein Programm zur Texteingabe, das einen möglichst wenig ablenkt – also so ziemlich genau das Gegenteil von Word. Und genau darüber bin ich heute ausgerechnet in einem kurzen Artikel bei der Financial Times gestolpert: “Schreib mal nieder“. In dem Artikel wird DarkCopy vorgestellt: Eine extrem reduzierte Texterfassung, die im Browser läuft und einem ein 80er-Jahre Retro Feeling verpasst – vorausgesetzt, man hat damals bereits an Computern gearbeitet.
Diese Online-Anwendung ist sicherlich sehr interessant zum ausprobieren, aber für den regelmäßigen Einsatz sollte man doch besser Software auf dem eigenen Rechner installieren. Für Mac-User gibt es die interessante Software Writeroom, die einem hochmodernen Mac so aussehen lässt, wie ein 1981er IBM-PC: Ausschließlich Grün auf schwarz, Bernstein auf Schwarz oder Weiß auf Blau. Keine Fenster, keine Menüs, keine Maus – nur Du und Dein Text.
Für Windows-Nutzer gibt es das nahezu baugleiche DarkRoom. Eine weitere Variante ist jDarkRoom, die auf jedem Rechner mit mindestens Java1.4 läuft.
Eine schöne Übersicht über Software, die das kreative Schreiben besser unterstützt, als Word, findet sich beim Literatur-café: “Kreative Schreibprogramme für MAC und PC – Eine Auswahl“.
Interessant. Je beliebter Twitter wird, desto mehr stören sich manche Nutzer an den Beschränkungen. Ich bin gerade durch eine Nachricht von Nicole Simon auf den Dienst TwitterBudgi aufmerksam geworden. Offensichtlich vermissten die Gründer so einige Features, die sie nun selber nachbauen:
Interessant finde ich das vor allem deshalb, weil einige dieser Funktionen und noch einige mehr in meinem ersten Prototypen von zzap enthalten waren. Das war 2006 kurz bevor Twitter online ging. Der Grund dafür war die Erkenntnis, wofür mobile Kommunikation im Wesentlichen genutzt wird:
Dementsprechend hatte ich Features vorgesehen, die sich auf schnelle, kurze Nachrichten, Gruppenbildung, Zeit- und Ortsangaben konzentrierten. Ich hatte einige Tags für die Kurznachrichten vorgesehen: ‘#’ für Orte, ‘@’ für Personen ‘!’ für Zeitangaben – kommt das jemandem bekannt vor? ;-). Man konnte Bilder und Kartenausschnitte an die Nachrichten hängen, um den Kumpels zu zeigen, wo man ist und warum es da gerade so toll ist…
Theoretisch war das alles sehr toll, es gab nur ein Problem:
Das war den Testpersonen zu komplex. Sie haben es entweder nicht verstanden, oder keine Lust das alles zu erlernen.
Und dann kam Twitter und konnte – fast nichts. Und genau das war der Urknall für das Multichannel – Groupmessaging, oder Microblogging, oder wie immer man das nennen will. Und jetzt kommt ein Service, der auf Twitter aufsetzt und all diese Features nachrüsten will? Ich bin da sehr, sehr skeptisch…
Einen wie ich finde recht guten Crashkurs in Marketing kann man bei iPlot finden:
“What Every Good Marketer Knows”
Interessant wird das Ganze durch scheinbare Widersprüche, wie einerseits “People are selfish, lazy, uninformed and impatient. Start with that and you’ll be pleasantly surprised by what you find.” aber auf der anderen Seite: “You can’t fool all the people, not even most of the time. And people, once unfooled, talk about the experience.”
Einerseits sind die meisten Punkte Binsenweisheiten, andererseits werden erstaunlich viele gerade auch von großen, bekannten Firmen ständig missachtet.
Ich habe vor gut zwei Wochen angefangen, zzap völlig neu aufzusetzen. So langsam bekommt das ganze Form. Einen Releaseplan habe ich auch schon ungefähr – jedenfalls was die Features bzw. Milestones angeht. Im Gegensatz zum ursprünglichen Konzept aus dem letzten Jahr will ich aber keinen Dienst betreiben, sondern die Software vertreiben – und zwar als Open Source.
Bloß welche Lizenz kommt dafür in Frage? GPL 2, GPL 3, BSD, …???
Wer kennt sich aus, wer hat sachdienliche Hinweise?