Nun habe ich endlich den Domainumzug geschafft. Die aktuelle Version von zzap ist online gestellt. Bis zum ersten Alpha-Release ist aber noch ein bischen Feintuning vonnöten. Insbesondere die Installation dürfte für ungeübte noch eine große Hürde darstellen, aber es geht langsam voran.
Da töne ich noch rum von wegen “Domainumzug” und dann funktioniert fast zwei Tage die Namesauflösung von zzap.de nicht. Die Domain war nicht mehr aufrufbar.
Wie meistens sitzt das Problem vor dem Rechner. Wenn man dem Nameserver keine A-records mitteilt, kann der natürlich auch keine Namensauflösung hinbekommen (ich Schussel). Habe eben die Einträge vorgenommen und dann auch gleich noch den reverse DNS gesetzt.
Wie ein Kollege von mir so schön sagt: “Kaum macht man es richtig – schon geht’s.”
Fein – dann kann ich ja endlich den neuen Content hochladen, wenn ich wieder daheim bin. Bis dahin gib es nur ein garstiges “Raw Space” zu sehen.
Heute bin ich umgezogen – bzw. meine Domain zzap ist auf einen anderen Server umgezogen. Da mir nunmehr endlich PHP5/MySQL5 und andere aktuelle Features zur Verfügung stehen, kann ich auch nun die neueste (Entwicklungs)Version von zzap dort installieren. Bisher lief dort noch die Version 3, die ich zur Web2.0-Expo 2007 programmiert hatte.
Nach knapp einem Jahr Entwicklungspause hatte ich die Konzeption überarbeitet. Von der ursprünglichen Idee, einen Service aufzubauen bin ich aufgrund der mittlerweile großen Anzahl ähnlicher Projekte (Twitter, Pownce, Jaiku u.a.) abgekommen. Ohne eine standesgemäße Finanzierung im Rücken, kann man gegen diese Konkurrenten nicht bestehen. Anstelle eines Services, soll nunmehr eine einfache Software treten, die es jedermann erlaubt, einen eigenen dezentralen Microbloggingdienst aufzusetzen.
Seit April arbeite ich nun nebenher an der neuen Software, die zwar im Frontend ähnlich aussieht, aber “unter der Haube” runderneuert wurde. Das zugrundeliegende Framework ist völlig überarbeitet und nutzt nunmehr die Features von PHP5 (Objektorientierung) und MySQL5 (UTF-8, Foreign Keys,…). Dafür habe ich Abschied von DB-Abstraktion Layern, diversen PEAR-Modulen und der Templateengine Smarty genommen, um externe Abhängigkeiten zu minimieren.
Die zentralen Features sind bereits fast alle lauffähig. Die nunmehr schon vierte Version von zzap ist sowohl per Webbrowser bedienbar und unterstützt zusätzlich Mobiltelefone mit automatischer Content-Anpassung, z.B. von Fotos für unterschiedliche Displaygrößen durch ADD (Automatic Device Detection). Man kann Kurznachrichten schreiben und ein Bild anhängen, die Nachricht auf twitter weiterleiten lassen und ein einfaches Badge in seinen Blog integrieren.
Für mich selber funktioniert der Dienst damit bereits recht gut, aber es bleibt noch eine ziemliche Menge Arbeit bis zum ersten Alpha-Release. Eine Baustelle ist zum Beispiel die noch nicht vollständig umgesetzte Mehrsprachigkeit. Für den Start sollte zzap mindestens Deutsch und Englisch unterstützen. Ein einsteigerfreundliches Setup ist noch nicht vorhanden und ein ganz zentrales Feature fehlt noch völlig: RUN, bzw. Remote User Notification. Das ist die Weiterleitung von Nachrichten an Kontakte, deren Account auf anderen Computern liegen.
Alles in allem ist diese Software also noch eine Riesenbaustelle, aber es geht allmählich voran. Stay tuned…
Seit eben gerade funktioniert mein zzap-to-twitter Interface endlich (wieder). Die dummen Kommentare in meinem Badge kommen alle vom Testen.
Was ist daran jetzt neu?
Bis vor 2 Wochen hatte ich ja bereits eine funktionierende Verbindung. Die jetzige Lösung unterscheidet sich aber in einem wichtigen Punkt: Nebenläufige Programmierung. Das bedeutet, daß das normale Skript, welches der Nutzer per Webbrowser aufruft, alle Arbeiten, die möglicherweise mehrere Minuten in Anspruch nehmen können, nicht selber ausführt, sondern an ein anderes Skript weiterreicht und sich selber beendet, während im Hintergrund die zeitintensiven Tasks weiterlaufen. Das ist eine Voraussetzung, um ein Benachrichtigungssystem für externe Systeme betreiben zu können.
Wo war das Problem?
Die Aufgabe war klar, aber es gibt immer 100 verschiedene Wege zum Ziel. Die ersten Ideen gingen in Richtung einer Task-Queue, also einem ständig im Hintergrund laufenden Skript, daß nachschaut, ob eine neue Aufgabe anliegt. Davon bin ich schnell wieder abgerückt, weil diese Lösung Overkill wäre und außerdem Probleme bei vielen Hosting-Providern verursachen würde, die ständig laufende Hintergrundprozesse ausschließen.
Es musste also etwas einfacheres her: Der eigentliche Worker-Prozess muss direkt vom Webscript gestartet werden.
Üblicherweise macht man so etwas mit dem exec() – Befehl in PHP. Das funktionierte auch wunderbar sowohl auf meinen Entwicklungssystemen (jeweils einmal Windows, Apple OS X und Sun OS), aber ausgerechnet auf meinem Live-System war das Skript nicht zum Laufen zu bekommen. Den Worker direkt auf der Kommandozeile zu starten war kein Problem, nur über den exec-Befehl in einem Web-Skript startete er nicht – unabhängig von allen Dateiberechtigen und Pfadeinstellungen. Ich vermutete schon, daß der Provider diesen Befehl aus Sicherheitsgründen einfach gesperrt hat, aber ein einfaches echo exec(‘whoami’) zeigte völlig korrekt den Owner des Webservers an. Um es kurz zu machen: Der ganze Kram hat mich gut eineinhalb Wochen gekostet und gestern hatte ich die Nase voll.
Die Lösung, die ich jetzt verwende ist richtig “basic”: Das Worker-Skript wird per HTTP über CURL aufgerufen. Ganz ohne Hakeleien ging auch das nicht ab, aber nun läuft es erst einmal. Ob diese Lösung auch einen Load von 1000 remote-calls verkraftet, weden wir dann sehen, wenn das Protokoll zum Nachrichtentausch funktioniert. Für heute bin ich jedenfalls erstmal zufrieden.
“Was schreibt der Kerl denn da für kryptisches Zeug in sein Microblog-Dings da links?”
“Was bedeutet ‘Test eines Scriptes’? Was will er damit eigenlich sagen?“
Die Antwort: Ich teste ein wichtiges neues Feature in zzap: asynchrones Messaging.
In zzap geschriebene Nachrichten sollen auch an andere Microbloggingsysteme weitergeleitet werden. Unter Umständen sind das sehr viele externe Systeme, wenn jemand viele “Follower” (twitter-Terminologie ) hat. Damit der Browser des
Schreibenden nicht minutenlang hängenbleibt, oder – noch schlimmer – die Verarbeitung durch Timeout abgebrochen wird, ist es nötig, diese Benachrichtigungen im Hintergrund laufen zu lassen, während die Anfrage vom Browser bereits beendet ist. Zur Zeit probiere ich das mit der twitter-Weiterleiung aus.
Leider bisher mit mäßigem Erfolg. Das Verfahren funktioniert zwar ganz hervorragend auf mehreren Entwicklungssystemen (Windows und Unix), aber ausgerechnet mein Live-Server zickt rum. Mal sehen, wie ich das Biest zähme. Bis dahin werden aber noch so einige scheinbar unsinnige Kurznachrichten erscheinen.
Habt etwas Geduld mit mir ;-)
Jason von 37 Signals hat auf dem Firmenblog einen interessanten Beitrag veröffentlicht: “Why we skip Photoshop“.
Er beschreibt darin den Designprozess von 37 Signals für Webprojekte. Es gibt zunächst Zeichnungen auf Papier mit denen das grundlegende Layout erarbeitet wird. Wenn diese funktionieren, wird sofort im Frontendcode gearbeitet – ohne den üblichen Zwischenschritt in einem Photoshop-Dummy. Als Gründe werden angegeben, daß man Photoshopdateien nicht anklicken kann, obwohl man sie bereits auf dem Bildschirm hat, man leicht durch unwichtige Details abgelenkt wird, man kann nicht schnell mal den Text austauschen oder sehen, wie sich die Seite dynamisch verhält. Photoshop unterstützt generell den Workflow in Gruppen nicht sinnvoll und führt dazu, daß man länger braucht, weil man vieles doppelt macht.
Prinzipiell kann ich da nur zustimmen – ich arbeite seit Jahren ähnlich. Mir fällt auch gleich noch ein weiterer Punkt ein: Wenn man gleich im 2. Schritt den Code schreibt, erkennt man sofort, was in welchem Browser nicht so funktioniert, wie man es sich vorgestellt hat. Die Massen an nicht in sauberen Code umsetzbaren PSDs sind Legion. Dan Boland kommentiert noch:
“Also, type in Photoshop never seems to be the right size as type in HTML . It just never seems to feel the same. It doesn’t wrap the same, it doesn’t space out the same.“
Ein interessantes Gegenargument spricht dafür cubiclegrrl in den Kommentaren an:
Sie gibt ihren Kunden NIEMALS klickbare Dummies an die Hand, weil diese nicht verstehen, daß es sich um einen Klickdummy und nicht bereits um die fertige Anwendung handelt (“Wieso brauchen sie denn so lange? Sie waren doch vor vier Wochen schon fertig.“). Unwissende Kunden fühlen sich dann oft übertölpelt, weil sie nicht wissen, wieviel Arbeit “unter der Haube” nötig ist. Sie bevorzugt deshalb Storyboards und Scribbles, auch wenn diese letztlich mehr Zeit benötigen.
Das richtige Tool für die richtige Phase im jeweiligen Projekt.
Struktur
Ich glaube, daß Scribbles und abstrakte Storyboards (oder Wireframe) genau die richtige Herangehensweise sind, um gleichzeitig den Content zu strukturieren, das Grundlayout anzulegen und zu überprüfen, ob das Ergebnis bedienbar ist.
Aussehen
Photoshop ist ein wirklich erstklassiges Bildbearbeitungsprogramm, nur habe ich es nie für ein Tool gehalten, mit dem man gut Websites “entwerfen” kann. Dafür ist es einfach nicht gemacht. Aber um festzulegen, wie der Mood einer Website ist, halte ich es dennoch für sinnvoll. Um sich dem grundsätzlichen Styles einer Site zu erarbeiten, sind ein-, zwei Screens recht mit einigen typischen Seitenelementen gut geeignet. Man darf nur nicht versuchen, die Seiten möglichst pixelgenau nachbauen.
Verhalten
Und zur Beurteilung dynamischen Verhaltens, benötigt man leider letztendlich codierte Prototypen. Es ist halt ein Unterschied, ob man eine “Website” mit viel Eye-Candy baut, oder eine Webapplikation.
Nicht zu vergessen, spricht m.E. ein gewichtiges Argument gegen Photoshop: €1.000.
http://dowebsitesneedtolookexactlythesameineverybrowser.com/
(kam gerade von Pieter)
Das Wochenende war nicht nur sehr schön, sondern auch ein erfolgreicher Test der nächsten Version von zzap. Aufmerksame Leser dieses Blogs werden an der rechten Spalte bemerkt haben, daß ich meine Kurzstatements nicht mehr per Twitter verschicke, sondern über den neuen Prototypen von zzap.
Während ich in Ahrenshoop und auf dem Darß die tolle Landschaft genoß, habe ich viel mit dem Handy fotografiert und ein paar Bilder mitsamt Kurznachricht verschickt. Die Textnachrichten werden auch an twitter weitergereicht und sind so auch meinen followers dort zugänglich, aber die Fotos entgehen ihnen dort. Die Software habe ich erst am Freitag abend installiert und ich war gespannt, ob alles funktioniert. Wie man am Blog sehen kann – es funktioniert.
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.
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.