Musste mich entscheiden und verzichte auf die "Server Side Javascript"-Session. Dafür hier den Anfang der Session verpasst wegen technischem Support. Der Beamer ließ sich mit meinem Akoya leider nicht richtig ansprechen. Jetzt aber zum Thema 
Tina Guenther bloggt hier und diskutiert mit uns über Vertrauensbildung im Internet (die Slides sind schon online). Ich hab gerade keine Lust, das alles live mitzutippen
Malte Münchert erzählt uns jetzt etwas zum Thema "Facebook-Chat für alle: Ajax-Push Queue (ApuQ). Ich bin gespannt. Er kommt aus Berlin und der Rails-Ecke.
Verbindung zum Server bis zu fünf Minuten offen halten. Client-seitiges Javascript zum Eventhandling, der Server muss die Ereignisse zum Browser schieben können. Malte hat einen Ruby-Server dafür geschrieben.
Herkömmliche Vorgehensweise: Polling vom Client, hat viele Nachteile. Beim eigenen Server muss man hinbekommen, dass er unter der gleichen URL und dem gleichen Port läuft. ApuQ-Framework und mod_proxy (Reverse Proxy) bzw. per PHP - andere Lösungen sind denkbar und werden gerade diskutiert. Der Facebook-Chat ist wohl in Erlang implementiert.
Auch hier der Disclaimer: Verlinkungen und weitere Infos folgen.
Martin Thielecke über Cloud Computing. Weltweite Verteilung der Rechenzentren, extreme Skalierbarkeit, schnelle Verfügbarkeit der Server, man zahlt nur, was man verbraucht. Nachteil: Kein direkter Zugriff auf die Hardware, um Backups usw. muss man sich selbst kümmern. Sinnvoll für Startups von Anfang an!?
Ambieter: Amazon (EC2, S3, SQS, SimpleDB, ECS, FPS), Google, Sun (Grid), Skytap, GoGrid; demnächst Host Europe und andere. Beispiel: Elastic Compute Cloud von Amazon. Es werden sehr viele Amazon Machine Images angeboten, diverse Systeme (Debian, RedHat, usw.), die einfach hochgefahren und dann zur S3 hochgeladen werden und public oder private zur Verfügung stehen. Monitoring, Starten, Beenden ist großteils über APIs möglich.
Persistenter Speicher: Elastic Block Store (EBS). Simple Queue Service ist ideal für asynchrone Computing-Aufträge, wird angesprochen über SOAP-API. S3: Reiner Speicherplatz für Dateien/Objekte bis 5 GB, getaggt mit Location, versehen mit Auth, REST- und SOAP-API. SimpleDB: Nicht-relationale Datenbank; "Domain", "Items", "Key-Value-Attributes"; simple API; ähnlich CouchDB(!).
Anmerkung: Das waren erstmal nur live mitgebloggte Stichworte; der Artikel wird möglicherweise später noch überarbeitet
Dieses Wochenende ist Barcamp im Essener Unperfekthaus, und ich fahre da gleich hin. Mehr dann wahrscheinlich morgen und übermorgen.
Update: Hier habe ich ein paar Fotos vom Barcamp hochgeladen.
Two days ago, Benjamin Nowack announced the re-release of Knowee, a distributed social web address book. Knowee started out as a project supported by the W3C Semantic Web Interest Group and will also available for download soon. This means you can install it on your own server, if you like.
Knowee is somewhat similar to NoseRub as it aggregates many of your profiles from popular social networks and applications like Twitter, Identi.ca, or Delicious. But Knowee adds a lot of semantic wizardry to all the data its bots collect over time. Among the technologies employed are FOAF, RDF, Microformats, OpenID, Google's Social Graph API, and SPARQL. The latter makes it easy to re-use the aggregated information in other applications. Without digging too deep into all these formats and APIs, let me say this seems to evolve into a very powerful tool, far more than a simple address book. For more info, read the introductory blog post, or simply take a shot at it.
That being said, I'm a little irritated about how little buzz Knowee has created so far (only 4[!] hits on Technorati?). Is everyone simply fed up with yet another social network aggregator? Or am I just a little bit too impatient? I don't know, but I know that Knowee deserves more attention even if it's still in an early stage. Especially since I'm sure that Benjamin will add more useful features soon, e.g. the integration of MyBlogLog.
My public Knowee profile can be found here.