BlogKontaktTagcloud

All new webtuesday

Looks like spring give us not only very nice weather but also a lot of cool new tech-events here in zurich. The webtuesday (un-)organizer anounced two new events lately.

First of all the regular monthly webtuesday meeting on Tuesday 13th May 2008 at 19:30. New this time is the location - we hang around at the big cablecom offices - and the speaker - day's CTO David Nüscheler. David is talking about "ujax in 30 minutes" where microjax "is a client sided javascript persistence layer that leverages the symbiosis of a (JCR compliant) Content Repository and the agile patterns of browser based ajax development". David is a great and experienced speaker and also the topic might give you some new insights about handling data in your application. It's all free, just add your name to the wiki. So see you there...

The second event might be even cooler. On Saturday 24th May 2008 you all are able to join the usually webtuesday crowd (great hackers from here, here and well erhm here) to hack some new stuff together or help the php community with new tests (or do both). If you have any great plans for a hack just enter your idea to the wiki. If you're a php developer you might help the community with giving some test back to your programming language. Writing tests for PHP should be easy enough for everyone (look at this presentation from Sebastian).
Ähnliche Beiträge:
Peter Zaitsev in Zurich
Last Minute Call for webtuesday
Ajax vs. Flash
Memcache with quicklz
Mobile App Hackathon
Comments (0)  Permalink

AJAX-Chat in PHP mit UNIX IPC

Das AJAX-Chats und ander Multi-User AJAX-Anwendungen nicht nur Clientseitig spezielle Technologien benötigen ist wohl den meisten klar. In Java bittet dazu Web-Continuations eine gute Hilfe um die Server-Last tief zu halten. Mit der Share-Nothing-Architecture von PHP ist eine solche Technologie jedoch nicht möglich.

Was tun wenn man nicht lange pollen will und so unnötig Resourcen auf dem Server blockiert. Meine Überlegung ist die IPC (interprocess communication) Funktionen von Unix zu verwenden um die Nachrichten auf dem Server auszutauschen. PHP unterstützt IPC bereits out-of-the-box.

Jeder Client erhält wenn er sich anmeldet eine eigene Message-Queue in die die für ihn bestimmte Nachrichten liegen. Die Nummer für die Queue muss eindeutig sein, die Nummer wird von mir aus einem Shared Memory Bereich gelesen (könnte aber ebenso gut mit einem File oder DB geschehen).

Für das Verteilen der Nachrichten an alle Clients wird ein kleiner Server (PHP-Script) gestartet, der ebenfalls eine Message-Queue hat. Alle von Clients geschrieben Nachrichten werden über die Queue an den Server gesendet und dieser Verteilt diese Nachricht dann an die Queues der Clients.

Da msg_receive über keinen Timeout verfügt, kann die Methode zum Abfragen der Queue nicht blockierend verwendet werden. Mit einem kurzen Sleep wird die Methode nun einfach maximal 30 mal aufgerufen. Sobald Daten in der Queue liegen werden diese an den Client geliefert und dieser fragt anschliessend erneut an. Werden keine Daten in die Queue gelegt wird dem Client ein 204 zurückgeliefert, worauf dieser ebenfalls erneut pollt.

Schematisch sieht das dann etwa so aus.



Das ganze ist ein Design-Studie. Wenn man ein solches System produktiv einsetzen möchte müsste man mindestens folgendes verbessern:
  • Mal überlegen ob das überhaupt funktioniert ;-)
  • Code für produktive Systeme sollte nicht so aussehen wie meiner hier!
  • Benutzerverwaltung
  • Zuordnen der Message Queues Nummer mit einem Semaphor schützen
  • Gesendete Nachricht beim Sender direkt mit JavaScript anzeigen (Verbesserte Usability, Response-Time)
  • Garbage Collecting von nicht mehr verwendeten Message Queues
  • Sicherheit der Message Queues mit korrekter Berechtigung
  • Wenn mehrere Messages in der Queue liegen diese zusammen übertragen.
  • Wer dann wirklich genug Zeit hat sollte die PHP (und Unix-Funktion) msg_receive mit einem Timeout ausstatten.
Denn Code kann man hier herunterladen. Wichtig ist das der Server (ipc-server.php) zuerst gestartet wird.

Zuletzt bleibt hier noch einen Dank an Georg für den Support bei meinen CSS Fragen.
Ähnliche Beiträge:
Parallel Request mit AJAX und PHP
Make it human (or how to crack a CAPTCHA)
Jira status
Mailstatus in Skype
PHP Quine
Comments (5)  Permalink

Loogel findet mehr

Meine eigene, kleine, tagbased Suchmaschine Loogel findet nun auch Einträge bei local.ch und zeigt Fahrpläne an.

Loogel sucht automatisch jeweils ob die aktuelle Tag-Zusammensetzung auch bei local.ch zu einem Treffer führt. Sollte dies der Fall sein wird ein Link eingeblendet. Die Anfrage an local geschieht mit snoopy und XML_HTMLSax. Das Ort wird noch nicht richtig in die Anfrage eingebunden, suchen nach "Meier Zürich" bringt also noch nicht das richtige Resultat.

Für den Fahrplan wird in den Tags, mit Hilfe der OpenGeoDB, nach Ortschaften gesucht. Bei einer oder mehr Ortschaften wird automatisch die Fahrplan-Eingabemaske (Web-1.0-Firma!) mit den ausgefühlten Felder eingeblendet. Hin und wieder kann es hier noch zu Encoding-Problemen kommen.

Technisch liesse sich in beiden Fällen noch einiges mehr machen, auf die Bekantschaft mit den Rechtsanwälten der jeweiligen Firma lege ich dann aber doch nicht allzuviel Wert (obwohl das sicher auch nette Typen sind ;-).
Ähnliche Beiträge:
Tag Searchengine LOOGEL based on Google and del.icio.us
del.icio.us-tagometer
Faster google maps with JSON
You shall not steal!
All new webtuesday
Comments (0)  Permalink

Web-Continuations - Technolgie 2007

Eigentlich wollte ich schon lange über Continuations und die Implementierung in Jetty schreiben. Nun sind mir andere jedoch zuvor gekommen.

Continuations tritt an um das Problem von häufig zu aktualisierenden Seiten zu lösen oder zumindest zu mildern. Der klassische Use-Case dazu ist wohl der HTTP-Chat.

Sollen neue Meldungen "sofort" angezeigt werden müssen diese regelmässig beim Server abgeholt werden, da es mit HTTP keine Möglichkeit gibt diese vom Server an den Client zu senden. Dauerndes Polling mit XMLHttpRequests ist eine "teure" Angelegenheit, damit werden, auch wenn es keine neue Nachrichten gibt, Client, Server und Leitung belastet. Der HTTP-Request kann nun auf dem Server blockiert werden und der Server gibt erst nach einer gewissen Zeit oder bei einer neuen Nachricht antwort. Das entlastet den Client und die Leitung, der Server braucht aber mindestens ebenso viele Ressourcen wie zuvor. Continuations greift nun genau da ein. Die Ausführung des Requests wird bis eine Nachricht auftritt ausgesetzt. Dies ermöglicht dem Server Ressourcen zu sparen.

Da sich im Jahr 2007 der Trend zu desktopähnlichen Webandwendungen fortsetzen wird, wird Continuations (oder ähnliche Techniken) dieses Jahr für Webentwickler wohl sehr wichtig.
Ähnliche Beiträge:
Scaling is not about...
Parallel Request mit AJAX und PHP
Synchroner Aufruf mit XMLHttpRequest in Firefox
Ajax vs. Flash
Faster google maps with JSON
Comments (0)  Permalink

Parallel Request mit AJAX und PHP

Das Ausführen von zwei parallelen Requests mit AJAX ist nicht ganz einfach, aber machmal Notwendig. Zu beachten ist das jeder Browser nur eine gewisse Anzahl gleichzeitiger Requests an den gleichen Server ausführen kann.

Ich ging also mutig ans Werk und habe das mal ausgetestet in dem ich einen kleinen Chat implementierte (dazu später mehr). Dazu habe ich das Prototype-Framework verwendet, dessen inoffizielle Dokumentation findet man hier. Eine Request pollt für neue Nachrichten, während ein anderer auf Befehl des Benutzers nachrichten sendet. Irgendwie gingen die Nachrichten nacheinander über den Äther. Ein Schuldiger musste her! Der Schuldige ist bei mir immer im Javascript-Teil zu suchen. Vermutlich setzte das bösse Prototyp-Framework die Request in Serie. Mit dieser Vermutung machte ich auf die Suche in der Doku, im Code (zum Glück nicht so viel Code) und mit FireBug zur Laufzeit.

Und schlussendlich war dann doch nicht der Client schuld. Der "Fehler" steckte im Serverteil und wenn ich mich in PHP nicht so sicher fühlen würde hätte ich vermutlich auch früher die Kommentare in der PHP-Dokumentation gelesen. Da hatte einer zur pre-AJAX Zeit mit Frames ein ziemlich ähnliches Problem. Ich habe beim benchmarken gemerkt das session_start() ewig hängen bleibt.

Der Grund dafür ist einfach und irgendwie logisch, wird eine Session in PHP geöffnet wird sie standardmässig bis zum Abschluss des Seitenaufbaus offen gelassen. Während dieser Zeit ist es nicht möglich die Session erneut zu öffnen, der Aufruf von session_start() blockiert bis die Session vom anderen Request geschlossen wird. Das war auch der Grund warum das Seiten nacheinander abgearbeitet werden.

Die Lösung ist in meinem Fall relativ einfach. In dem lange dauernden Request greife ich nur auf eine einzige Variable lesend zu. Ich lese deshalb nach dem Öffnen der Session die Session-Variable in ein lokale Variable ein und schliesse danach die Session mit session_write_close() gleich wieder. Danach gehts auch mit zwei parallelen Request ohne Probleme und der JavaScript-Teil ist für einmal entlastet!
Ähnliche Beiträge:
Synchroner Aufruf mit XMLHttpRequest in Firefox
Webtuesday: PHP wins!
Webtuesday: PHP vs. Javascript: which sucks more?
Faster google maps with JSON
Make it human (or how to crack a CAPTCHA)
Comments (8)  Permalink

Tag Searchengine LOOGEL based on Google and del.icio.us

Nun habe ich mir meine eigene Suchmaschine gebastelt. Weil das Durchsuchen des gesamten Internets ein wenig Zeitaufwändig ist, greife ich auf den Index von Google zurück. Dazu verwende ich das Google AJAX Search API, weil das SOAP API von Google leider nicht mehr öffentlich verfügbar ist. Das AJAX API ist für die kreative Verwendung ein wenig eingeschränkt, deshalb habe ich es "aufgebohrt", sprich die Anzeige ein wenig erweitert.

Einfach Google nachbauen bringt aber wenig, ich habe desshalb die Suchresultate von Google mit Informationen von del.icio.us kombiniert. Zu jedem Suchresultat werden die Tags aus del.icio.us angezeigt, aus Performance- und Darstellungsgründen allerdings . Ganz nach dem Motto "Ein Tag ist kein Tag" werden nur Tags angezeigt die mehr als einmal vorkommen. Den Tags die nur von einem Benutzer verwendet werden sind öfters nicht nützlich. Unter der Suchmaske werden die 20 meist genanten Tags für die Suchresultate angezeigt, sie können direkt zur Suche hinzugefügt werden. Die Informationen werden mit RSS von del.icio.us mit MagpieRSS bezogen.

Das ganze ist alles Web 2.0 und AJAX, für die Usability ist das aber in diesem Fall nicht unbedingt ein Vorteil. Da die Seite erst im Browser zusamengebaut wird, verschiebt sich während des Aufbaus noch so einiges.

Und hier gehts zu meiner tagbased Searchengine LOOGEL.

Die Term of Service des Google API wird hier wohl ein wenig stark "gedehnt", wenn das Ding nicht mehr läuft hat mir Google wohl den Hahn zugedreht (und ich werde vieleicht auf das Leistungsfähigere API von Yahoo umsteigen).
Ähnliche Beiträge:
Loogel findet mehr
del.icio.us-tagometer
Faster google maps with JSON
You shall not steal!
All new webtuesday
Comments (5)  Permalink

WikiWay2.0

WikiWay2.0 ist da! Mit WikiWay2.0 ist es möglich die kürzeste Verbindung zwischen zwei Wikipedia-Artikeln zu finden. So ist es zum Beispiel erstmals möglich die Verbindung zwischen einem Gürteltier und Bier aufzuzeigen. Dieses interessante Wissen wahr bisher gelangweilten Informatikern (ich nenne keine Namen!), die diese Informationen in müsamer Handarbeit zusammentrugen, vorbehalten.

WikiWay2.0 ist auch ganz schön Web2.0: Da werden Scriptsprachen verwendet (PHP, Javascript), wie wild XMLHTTPRequests verschickt, Bilder "gemashupt" und natürlich ist das ganze auch noch ganz schön Beta. Leider ist Rechenleistung noch immer nicht unendlich und deshalb kann eine Anfrage manchmal ganz schön lange gehen, das Warten lohnt sich aber fast immer.

Und wer jetzt den Sinn dieser ganzen Applikation noch nicht versteht - das ist nicht so schlimm, ist schliesslich Web2.0.
Ähnliche Beiträge:
Synchroner Aufruf mit XMLHttpRequest in Firefox
Viele Daten II
Viele Daten
All new webtuesday
AJAX-Chat in PHP mit UNIX IPC
Comments (8)  Permalink

Synchroner Aufruf mit XMLHttpRequest in Firefox

Ein synchroner XMLHttp-Aufruf in JavaScript ist theoretisch nicht so schwer. Die Dokumentation ist, wohl weil synchrone Aufrufe im Vergleich zu asynchronen relativ selten benötigt werden, eher spärlich und teilweise verwirrend. Das grösste Problem ist dass das XMLHttpRequest-Objekt sind nicht in allen Browsern gleich verhält. So lässt sich der untenstehende Request im Konqueror (und wohl auch in älteren Internet Explorern und Safari) ausführen, obwohl der Aufbau eigentlich falsch ist.

//Not valide Request!
xmlHttp.open('GET', 'json.php?name='+name, false);
xmlHttp.onreadystatechange = function () {
if (xmlHttp.readyState == 4) {
var resp = eval(xmlHttp.responseText);
saveVar.c = resp['id'];
if(vonNr.c && zuNr.c){
foundIDs();
}
}
};
xmlHttp.send(null);
Diese direkte Umwandlung des asynchronen Request in eine Synchronene ist nicht zulässig und funktioniert deshalb im Firefox (und vermutlich in anderen Browser die den Mozilla-Kern verwenden) nicht. Der korrekte asynchrone Aufruf sieht wie folgt aus:

xmlHttp.open('GET', 'json.php?name='+name, false);
xmlHttp.send(null);

var resp = eval(xmlHttp.responseText);
saveVar.c = resp['id'];
if(vonNr.c && zuNr.c){
foundIDs();
}
Wobei in diesem Fall die Methode send blockierend ist und auf die Antwort vom Server wartet. Der nachfolgende Code wird erst nach dem send eine Antwort erhalten hat ausgeführt.
Ähnliche Beiträge:
Parallel Request mit AJAX und PHP
Faster google maps with JSON
Web-Continuations - Technolgie 2007
"Defekte" for-in-Schleife in JavaScript
Assoziative Array nach Value sortieren
Comments (2)  Permalink

Ajax vs. Flash

Gestern Abend war ich am Webtusday bei Bitflux direkt an der lautesten Strasse Zürichs.

Chregu und Gere haben ihren, bereits an der EuroAjax gehalten, "Kampf" "Ajax vs. Flash" wiederholt. Was an der EuroAjax als Show-Kampf abgehalten wurde, galt diesmal ernst ;-) Um es gleich vorweg zu nehmen: Ich glaube Gere hat mit irgendwelchen rhetorischen Tricks gewonnen. Das Resultat war am Schluss 26:22 für Flash obwohl Gere Chregu öffters Punkte geschenkt hat.

So jetzt aber im Detail noch einige Dinge die Interessant fand (ein bischen Flash lastig). Beim SEO scheint AJAX die Nase ein wenig vorne zu haben, da statische, maschinenlesbare Seiten einfacher erzeugt werden können. Flash hat bei Cookies klar gewonnen, die Fähigkeit Cookies mit unendlicher Grösse anzulegen hat sehr überzeugt. Natürlich ist auch die Crossdomain-Funktionalität in Flash ausgereifter als in AJAX. Chregu musste dann zwischendrin mal noch anmerken das er ohne den Browser aus Redmond locker gewinnen würde. Gere auf der anderen Seite zeigte sich nicht sehr begeistert von den geschäftsgebaren der neuen Flash Besitzers Adobe.

Bei den Multimedia-Fähigkeiten konnte AJAX Flash nicht viel entgegenheben. Flash kann auf Mikrofon und Kamera zugreifen, Töne erzeugen und auch Content streamen. Für das Streaming gibt es auf der Server-Seite auch Open Source Lösungen, zum Beispiel red5. Bei den Arbeitskräften hat Flash dann wieder verloren. Flash-Programmierer die wirklich Ahnung vom Programmieren haben (SOAP, OO, Gui-Library etc.) scheinen Mangelware zu sein.

Natürlich wurde während des ganzen Fights ein wenig Äpfel mit Birnen verglichen. Flash eignet sich eher für RIA-Anwendungen, AJAX eher für contentlastige Webapplikationen. Flash wird in Zukunft wohl (ebenso wie AJAX ) einen Aufschwung erleben. Die Natelunterstützung von Flash könnte sich als grosser Vorteil erweisen, während AJAX auf dem Natel mit den verschiedenen Browsern vermutlich einen rechten Kampf haben wird.

Das die beiden Welten nicht komplett verschieden sind zeigt zum Beispiel OpenLazlo auf, das aus einem Code sowohl Flash-, als auch AJAX-Applikationen erzeugt.Bleibt mal noch einen Fight zwischen Java-Applets und Flash auszufechten. Vieleicht können wir dann endlich die leidige Diskusion mit den Applets (samt Applets) beerdigen.
Ähnliche Beiträge:
All new webtuesday
Web-Continuations - Technolgie 2007
Zeitplanung bei Webprojekten (nichts als die Wahrheit)
Running Images goes Web 2.0
100@facebook
Comments (7)  Permalink

Faster google maps with JSON

Vor einiger Zeit habe ich mit Google Maps eine einfache Karte erstellt mit welcher Webseiten, die bei Geourl gelistet sind, angezeigt werden können. Heute habe ich nun, inspiriert durch einen Artikel, eine weitere Karte die mit JSON läuft zusammengebastelt.

JSON ist ein Subset von JavaScript welches für den Austausch von Daten definiert wurde, somit also quasi eine Art DTO erzeugt. Das Tolle dabei ist das ein übertragener JSON Text direkt mit "eval" in JavaScript als Objekt-Struktur geladen werden kann und so kein zusätzliches Parsing benötigt und die übertragenen Daten relativ kompakt sind.

Der Nachteil ist das auf der Serverseite, in diesem konkreten Fall, einiges mehr erledigt werden muss. Bisher reichte es den Rss-Stream von Geourl mit "readfile" durchzuschleifen und die übergebenen Parameter aus Sicherheitsgründen kurz zu überprüfen.

Nun muss das RSS-File auf dem Server geparst werden (geschieht in meinem Fall mit der netten Magpie RSS Bibliothek) und zu einer JSON-Struktur umgebaut werden bevor es an den Client ausgeliefert werden kann. Dieser kann dann das ausgelieferte File, wie schon erwähnt, nur noch mit "eval" laden.

Der direkte Vergleich der alten Lösung mit der neuen JSON-Lösung zeigt das die neue Lösung schneller ist. Wieviel schneller lässt sich aber wegen der relativ ungenauen Messung leider nicht sagen. In der, bei beiden Lösungen, nun angegebenen "parse time" ist nur das Clientseitige Parsen, respektive Laden, und erzeugen der Markierungen angegeben.

Für andere Projekte können auch andere im "Ajax serialization"-Artikel erwähnte Technologien interessant sein. Für klassische Webseiten ist AHAH vermutlich in vielen Fällen ausreichend.
Ähnliche Beiträge:
Parallel Request mit AJAX und PHP
Synchroner Aufruf mit XMLHttpRequest in Firefox
Loogel findet mehr
Web-Continuations - Technolgie 2007
"Defekte" for-in-Schleife in JavaScript
Comments (1)  Permalink
1-10/10