Einträge unter 'Web 2.0'
29. Dezember 2007 von okiess
Kurz vor Weihnachten hatte ich beschloßen, die rollacastr Anwendung von Rails 1.2.6 auf 2.0.2 zu migrieren. rollacastr ist ein Social Network für Podcast Hörer und hilft dir neue Podcasts über Freunde zu finden. Der Grund für das Upgrade war das verbesserte View Rendering/Mimetype System, mit dem es in Rails 2 möglich ist, neue Formate neben html, xml und js selbst zu definieren und eigene Views dafür zu nutzen.
Da wir bei rollacastr eine iPhone Variante entwickeln wollten, war dieses Feature sehr wichtig für uns und sollte den Aufwand für das Upgrade rechtfertigen.
Gesagt, getan… rollacastr ist eine überschaubare, standard-konforme Rails 1.2 Anwendung, die mit einer Handvoll gängiger Plugins (acts_as_taggable, open_id_authentification, restful authentification etc.) auskommt und größtenteils auf den Restful Ansatz verzichtet.
Nach der Installation des rails 2.0.2 Gem’s ging es im ersten Schritt daran, den Source Code und die Konfigurationsfiles auf den neusten Stand zu bringen. Für diese Umstellung habe ich mich an diesem hilfreichen Blog Post orientiert. Die meisten der dort beschriebenen Vorgehensweisen habe ich durchgefürt. Zuerst habe ich im Anwendungsroot “rails .” ausgeführt, um Konfigurationsfiles, Javascript Libs etc. auf den neusten Stand zu bringen. Seit Rails 2 wird standardmäßig ein Cookie-basiertes Sessionmanagement verwendet, worauf wir bei rollacastr (derzeit noch) verzichten, da wir unsere Sessions in der Datenbank speichern (Cluster). Der Cookie Session Ansatz ist sicherlich auch interessant, sehr schnell, aber auf eine Maximal Größe von 4096 Bytes beschränkt.
Danach habe ich einen Deprecation Check durchgeführt und ein paar View Methoden aktualisiert. Auf das Umbenennen aller Views habe ich verzichtet, da ich festgestellt habe, dass das nicht zwingend nötig ist. Denn es wird eine View eines spezifischen Formats verwendet, wenn sie vorhanden ist, auch wenn der Rest der Anwendung dieser Konvention nicht folgt. Daher habe ich mich darauf beschränkt, nur die wenigen iphone Views in der neuen Schreibweise zu verwenden (”NAME VIEW”.”FORMAT”.”BUILDER” also zum Beispiel: index.iphone.erb oder show.js.rjs).
Zudem habe ich festgestellt, dass wenn man alle Views in der neuen Schreibweise verwendet, die RJS Actions Probleme machen, da diese nicht mehr per Default verwendet werden, wenn sonst kein View Format vorhanden ist, was dazu führen würde, das man bei allen Actions die entsprechende “respond_to” Anweisung für “js” einfügen müsste…
Nach der Umstellung liefen alle Testfälle durch und die Anwendung funktionierte im Development Modus (unter OSX Leopard) einwandfrei.
Nun ging es daran, die Server für die Umstellung vorzubereiten. Dafür wurde auf allen Cluster Nodes, die unter Debian Etch Linux laufen, das Rails 2.0.2 Gem installiert. Danach habe ich dann das Deployment mit Capistrano angestoßen und dieses lief ohne Fehlermeldung durch. Leider musste ich zu meiner Überraschung feststellen, dass die Anwendungsprozesse nicht liefen… Keine Ruby Prozesse auf den Application Cluster Nodes und kein Eintrag in den entsprechenden Production bzw. Staging Logfiles. Hmmm….
In so einem Fall ist es immer gut, im Anwendungsroot eine Console zu öffnen, in der man meistens sinnvolle Hinweise bekommt, da dort auch das Rails Environment geladen wird. Hier bekam ich dann auch genau den Hinweis, den ich brauchte. Rails 2 benötigt eine Rubgems Version >= 0.95! (Debian Etch läuft aber unter Rubygems 0.9.0 und es gibt kein aktuelleres (stabiles) Paket) Zudem wurde empfohlen gem update —-system durchzuführen. Diesen Befehl hätte ich lieber nicht ausgeführt, denn danach musste ich festzustellen, dass der “gem” Befehl nun gar nicht mehr funktionierte!
Auch ein Downgrade auf die alte Gem Version durch “apt-get” funktionierte nicht mehr! Dadurch war ich leider gezwungen mir die benötigte rubygems Version selber zu kompilieren, was ich normalerweise um jeden Preis vermeide, um alle Cluster Nodes mit dem geringsten Aufwand zu installieren, aktuell zu halten und zu automatisieren. Da gerade Rubygems 1.0 rausgekommen war, wollte ich direkt die aktuellsten Version nutzen.
Damit ging die Leidensgeschichte dann leider weiter, denn ein paar der Gem Abhängigkeiten, die rollacastr benötigt funktionieren leider mit Rubygems 1.0 nicht. Das waren das feedtools und das ruby-openid Gem, die beide leider den “require_gem” Befehl nutzen, der aus Rubygems 1.0 entfernt wurde!
Das feedtools Gem ist gnadenlos veraltet und darauf könnte rollacastr gegegenbenfalls auch verzichten, aber ruby-openid Gem wird in jedem Fall benötigt. Für das ruby-openid Gem gab es neuere Version, die mit Rubygems 1.0 konform ist, leider funktionierte das neue Gem aber nicht mehr mit dem älteren Rails Plugin… 
Also war das auch kein gangbarer Weg…
Daher habe habe ich Rubygems 1.0 wieder entfernt und mir Rubygems 0.9.5 selbst kompiliert. Danach liefen alle benötigten Gems und Plugins und die Anwendung ließ sich starten…
Puh, eine Menge Ärger für ein paar iPhone spezifische Views…
Mein Fazit: Prüft eure Produktionsumgebungen genau, ob sie für die neuen Gegebenheiten ausgelegt ist! Natürlich ist das eigentlich eine Selbstverständlichkeit, aber ich hatte die Rubygems Anforderung überhaupt nicht erwartet und eine solche Anforderung einer speziellen Rubygems Version bisher auch noch nicht mit Rails erlebt. Ich hatte mir eher ein “Drop In Replacement” des neuen Rails Gem’s vorgestellt… 
10. Dezember 2007 von okiess
Wie bereits in diesem früheren Blog Post angedeutet, habe ich nun angefangen einen OpenSocial Container in Ruby on Rails zu implementieren. Die OpenSocial API besteht aus Sicht des Anwendungsentwicklers auf einer clientseitigen JavaScript und einer serverseitigen XML Rest API. Ich habe für mich entschieden, mich nur auf die serverseitigen Data API’s zu konzentrieren.
Die clientseitige JavaScript API soll Anwendungsentwicklern grundsätzlich den Einstieg in das Thema OpenSocial erleichtern und mit Kenntnissen von HTML und JavaScript ermöglichen, vollständige Social Apps für einen OpenSocial Container zu schreiben. Nunja, nach der Betrachtung der JavaScript “Interfaces” und der Sample Container Implementation, muss ich gestehen hatte ich wenig Lust mehr, einen eigenen Container zu entwickeln. Die JavaScript API basiert auf dem Google Gadgets Prinzip. Als serverseitiger Entwickler muss ich gestehen, dass mich die JavaScript API nur wenig reizt und ich finde sie auch außerhalb des Google Anwendungskontextes schwer umsetzen. Zudem finde ich es schlicht gesagt den falschen Ansatz und ich bin wirklich erstaunt, dass die OpenSocial kompatiblen Sites und Social Networks sich auf diese API eingelassen haben…
Ich für meinen Teil habe ich mich auf die Data API’s und die OpenSocial Authentifizierung konzentriert. Diese sind straightforward und basieren zum Größtenteil auf dem standardisierten Atom Syndication Format. Hier sehe ich auch den eigentlichen Benefit für den Anwendungsentwicklern, der die serverseitige API nutzt: Der Client ist mit Hilfe einer Atom Client API schnell erledigt! Selbst Firefox kann die Datafeeds direkt darstellen.
Die Authentifizierung funktioniert bereits und auch die People und Activities API sind schon teilweise umgesetzt. Bei der Acitivities API habe ich bisher nur den Readonly Teil umgesetzt, also die Ausgabe eines Userlevel Feeds. Zuletzt steht dann noch die Persistence API an.
Was übrigens in den OpenSocial Data API’s nicht durch die Atom API abzubilden ist, wird beispielsweise durch Elemente der Google Commons API ergänzt. Insgesamt ist die ganze OpenSocial Data API eine Mischung aus bestehenden Datenformaten und Spezifikationen. Ich würde sogar vermuten, dass hier nichts Neues entwickelt wurde, sondern nur “schnell” bestehende API’s miteinander kombiniert wurden. Hier sollte wohl schnell “ein Mittel” gegen Facebook gefunden werden…
19. November 2007 von okiess
rollacastr ist letzte Woche still und heimlich in die “Private Beta” Phase gegangen. Durch die ersten eingeladenen Benutzer sind nun auch schon ein paar “Bugs” gefunden und ein paar kleinere Features ergänzt worden. Bisher läuft alles rund und es werden weitere Einladungen verschickt.
Was ist rollacastr? rollacastr ist ein Social Network für Podcast Hörer und hilft dir neue Podcasts über Freunde zu finden. Podcasts können in Listen gepflegt, durch andere Mitglieder kommentiert und durch Tags mit anderen Podcasts und Mitgliedern verknüpft werden. So eine Art “Twitter” für Podcasts…
Wenn alles gut geht, soll rollacastr im Laufe des Dezembers in die Public Beta Phase gehen und somit für jeden zugänglich sein. Derzeit suchen wir noch Tester, die Zeit und Lust haben rollacastr auszuprobieren. Bevorzugt sind Podcaster und aktive Podcast Hörer, die sich mit dem Bereich auskennen und Spaß haben “Inhalte” einzupflegen. Gesucht sind auch Blogger, die Interesse haben, rollacastr auszuprobieren und gerne einen “Review” darüber schreiben wollen. Bitte einfach per Email (oliver*at*rollacastr*dot*com) anfragen.
9. November 2007 von okiess
Ich war gestern Nacht beim iPhone Europa Verkaufsstart bzw. Presse Event vor dem T-Punkt in der Schildergasse in Köln. Dort wurde um Mitternacht der Laden geöffnet, um den ersten iPhone Verrückten ihr Gerät inkl. Vertrag zu verkaufen.
Mein Kumpel Stefan und ich sind gegen 23.00h eingetroffen und haben mehrere hundert Leute vorgefunden, wovon bestimmt über die Hälfte Presse war. Da es in Strömen geregnet hat, haben wir bald Zuflucht unter einem der riesigen T-Mobile Schirme gesucht. Zudem wurden Decken und warme Getränke verteilt.
Insgesamt war der iPhone Verkaufsstart natürlich eher ein Presse Event und weniger etwas für Fans. Als die Tür dann endlich um Mitternacht aufging, hat man draussen nichts mehr mitbekommen. Nicht mal jubelnde iPhone Fans, die aus dem Laden gekommen sind. Keine Leinwand mit Bildern von drinnen, kein Feedback, nichts… Nur die Leute vorne in der Schlange wussten was drinnen passiert. Uns wurde dann irgendwann kalt und nass und wir sind gegen 01.00h nach Hause gefahren… Ich werde gleich in die Stadt und mir in Ruhe ein iPhone kaufen.
Mein Kumpel Johannes hat übrigens als Erster sein Handy bekommen… Unglaublich! Herzlich Glückwunsch, Johannes!
3. November 2007 von okiess
Wie man bereits überall im Netz lesen kann, hat Google am 1. November die Verfügbarkeit der OpenSocial API bekannt gegeben. Eine Reihe von führenden Social Networking Sites wie z.B. MySpace, LinkedIn, Xing etc. haben sich dieser Initiative angeschlossen und werden diese standardisierte API in Ihren Sites anbieten.
Für Social Networking Sitebetreiber bedeutet dass, das deren Sites als Umgebungen bzw. Container dienen, um Drittanbieter Anwendungen (oder auch Widgets, Gadgets und Social Applications genannt) integrierbar zu machen. Der OpenSocial Ansatz ist also eine deutliche Konkurrenz zu Facebook, dem Markführer für Social Applications, die sich dieser Initiative nicht angeschlossen haben.
Für Social Application Entwickler (Drittanbieter) bedeutet dies, ihre Anwendung ohne großen Aufwand in alle OpenSocial konformen Social Networking Sites integrieren zu können. Zum jetzigen Zeitpunkt kann man auf diesem Wege theoretisch 200 Millionen Social Networking Benutzer erreichen…!
Nach einer kurzen Recherche auf den OpenSocial konformen Sites habe ich allerdings noch keine Möglichkeit gefunden, die API real nutzen zu können. Meines Wissens nach gibt es derzeit nur die offizielle Doku von Google und eine “Sandbox” auf Orkut (dem Google angehörigen Social Network), in der man mit der API herumspielen kann. Die OpenSocial API existiert als eine JavaScript-basierte Clientseitige Implementation und eine REST-basierte Serverseitige Implementation.
OpenSocial ist somit ein Programmiermodell und keine zentrale API von Google. Google wird keine Daten halten, sondern hat diesen Standard definiert. Google ist somit mit Orkut (sehr beliebt in Brasilien und Indien) selber ein OpenSocial Container.
Der Nutzen für Social Networking Benutzer ist meiner Meinung nach eher gering. Es wird maximal die Vielfalt von Drittanbieter Anwendungen erhöhen. Da ich allerdings denke, dass die meisten Leute nur 1-2 Sites intensiv nutzen, bringt OpenSocial dem Benutzer recht wenig. Auch die theoretische Möglichkeit der Übertragbarkeit von Profilen von Site zu Site wird warscheinlich eher (noch) nicht passieren. Das liegt wohl hautpsächlich daran, dass die Sitebetreiber an der Mitgliederanzahl gemessen werden und damit wirklich ihr Geld verdienen, genauer gesagt durch gezielte, profilbasierte Anzeigen und indirekt wenn es um den Verkaufspreis der Site geht. Eine einfache Übertragbarkeit werden die meisten Sitebetreiber (leider) eher verhindern wollen.
Für kleinere, unspezialisierte Social Networks werden die Zeiten jetzt noch schwieriger und deren Sites immer unattraktiver. Ich denke sowieso, dass OpenSocial nur für die großen Player im Markt interessant ist. Der Aufwand einen OpenSocial Container anzubieten, lohnt sich erst ab einer hohen Mitgliederzahl oder man ist Markführer in seiner Niche.
Ich als Entwickler werde mich natürlich mit der API beschäftigen und erstmal eine HelloWorld Testanwendung schreiben. Zudem überlege ich mir einen OpenSocial Container in Rails zu implementieren…
22. Oktober 2007 von okiess
Vor ein paar Tagen hat MySpace Co-Founder and CEO Chris DeWolfe bei der O’Reilly Media Web 2.0 Konferenz in San Francisco bekannt gegeben, dass MySpace in wenigen Monaten eine Anwendungsplattform für Drittanbieter im Stil von Facebook ermöglichen wird. Die Entwickler dieser “Widgets” sollen auch anteilig von den Anzeigen Umsätzen profitieren und auch in “speziellen Bereichen” eigene Anzeigen verkaufen können.
MySpace mit seinen 110 Millionen Mitglieder könnte somit finanziell einiges attraktiver für Drittanbieter und Widget Maker als Facebook und andere sein. Ich persönlich finde die Facebook Plattform technisch schon recht ausgereift und kann mir das bei MySpace nur schlecht vorstellen. MySpace sieht immer noch wie “Alpha” Software aus, ist häßlich, unzuverlässig, schlecht durchdacht und chaotisch. Aber auch in Deutschland sind sie immer noch das führende Social Network. Nur ob diese Funktionalität in Deutschland auch sofort zur Verfügung stehen wird, ist mir nicht bekannt.
Ich bin inzwischen ein großer Fan von “integrierten Anwendungen”, die in einem bekannten Social Network eingebettet sind. Ich denke, es macht sehr viel Sinn eine spezialisierte Anwendung in den Rahmen eines großen Social Networks zu integrieren, statt von Null anzufangen und tausende Benutzer (oder Millionen… ;)) für sich zu gewinnen. Denn am Ende wird der Social Networking Bereich aus einer handvoll führender Social Networks bestehen. “Vertikale Social Networks” machen sicherlich Sinn, aber warum muss man dafür unzählige eigenständige Plattformen betreiben und nicht von existierenden Benutzergruppen und Nutzerbeziehungen eines bestehenden Social Networks profitieren…?
7. Oktober 2007 von okiess
Am Ende des letzten Jahres hatte ich die Idee ein Social Network für Podcast Hörer ins Leben zu rufen. Es war die Zeit, in der Twitter gerade populär wurde und ich festgestellt habe, das es eigentlich eine “Art Twitter für Podcasts” geben müsste. Denn mal ganz ehrlich, wie findet Ihr eigentlich neue Podcasts? Indem ihr durch endlose Podcast Verzeichnisse stöbert oder die langweile iTunes Podcast Top 10 betrachtet…? Also ich nicht. Ich finde neue Podcasts durch Freunde und andere Podcast Hörer. Durch die einfache Frage “Sag mal, was hörst du eigentlich für Podcasts?”
Das ist rollacastr in einem Satz zusammengefasst. rollacastr ist eine Site, in der man eine Liste der Podcasts, die man hört, pflegen und schon in rollacastr bestehende Podcasts (z.B. die der Freunde) der eigenen Liste hinzufügen kann. Durch die Freunde in rollacastr bleibt man ständig auf dem Laufenden, was die zur Zeit hören oder welche Podcasts sie wie kommentieren. Es ist eine Site zum Entdecken von neuen Podcasts, Shows und digitalem Content.
Anfang diesen Jahres habe ich dann ein Team formiert und das Projekt ins Leben gerufen. Neben unserem Tagesgeschäft haben wir dann rollacastr konzipiert, gestaltet und in Rails programmiert. Da Podcasts in meinen Augen ein globales Thema sind, haben wir uns dazu entschlossen die Anwendung komplett in Englisch aufzusetzen, mit der Hoffnung die Kernmärkte USA, UK und Deutschland zu erreichen. Die Nutzung von rollacastr ist sehr einfach und benötigt keine herkömmliche Registrierung, sondern es wird lediglich eine eigene OpenID Identität vorausgesetzt. Wer noch keine OpenID besitzt, kann sich hier eine Kurzeinführung durchlesen und sich bei einem kostenfreien OpenID Provider anmelden. Mit dieser OpenID Identität können dann auch noch viele andere Websites benutzt werden, ohne dass man sich ständig neue Benutzerkonto anlegen muss. rollacastr erfasst also nur sehr wenige Benutzerdaten und alle Profilangaben sind optional.
rollacastr wird in Kürze in die Private Beta Phase gehen (Invitation Only). Bei Interesse kann man mich gerne zu diesem Thema kontaktieren.
4. Oktober 2007 von okiess
Als ich mich mit Swiftiply beschäftigt habe, habe ich mir Amazon EC2 als “On-Demand Serverinfrastruktur” bzw. Amazon S3 als “On-Demand Storage” angeschaut. Da diese Art internet-basierter Services im Kommen sind, habe ich mal nach weiteren Anbietern in diesem Bereich geschaut.
Hier ist eine Liste der Dienstleister, die ich bisher gefunden habe:
MediaTemple GridService
Mosso - The Hosting System
Nirvanix
FlexiScale
5. September 2007 von okiess
Vor ein paar Tagen habe ich das betahouse im Web entdeckt. Beim “betahouse” in Cambridge, USA geht es um eine Möglichkeit als Gründer bzw. unabhängiger Webentwickler Office Space, Infrastruktur und “soziale Verbindungen” in Anspruch zunehmen. Das Ganze gibt es für 200-400 US Dollar im Monat. Ich würde mir wünschen, dass es solche “Einrichtungen” auch in Deutschland gäbe, denn ich denke Geld allein ist für einen Gründer heutzutage nicht das Wichtigste. Sich komplett über das Internet zu organisieren ist durchaus möglich, aber “menschlich” und “psychologisch” doch oft schwierig. Räumlich kostengünstig beisammen zu sein (zumindest zeitweise) hilft auch jeden Fall. Also, liebe deutsche Copycat’s, hier gibt es was zu tun…
31. August 2007 von okiess
Ich hab mir gerade ein Video angeschaut von einer Facebook Entwickler Konferenz in Palo Alto. Für alle die sich für das Thema “Facebook Plattform” interessieren, gibt es hier einige sehr praktische Informationen, wie man erfolgreiche Applikationen auf Facebook erstellt.
Ich beobachte das Thema “Facebook Applikationen” schon einige Zeit und war anfangs sehr kritisch. Inzwischen bin ich allerdings der Auffassung, das die “Integration” bzw. “Integriertheit” von Sozialen Applikationen und Services wirklich das nächste große Ding ist. Ich würde heute sogar Leuten, die ein Social Network starten wollen, raten auf jeden Fall zweigleisig zu fahren und ihre Software Architektur darauf auszulegen “standalone” und in Facebook “integriert” lauffähig zu sein. Der Markt für Social Networks ist schwierig genug, wie kann man da noch eine große Anzahl von Leuten für sich begeistern?
Ein Social Network technisch auf die Beine zu stellen, ist nicht die große Herausforderung, sondern das Aufbauen einer wirklichen “Community” an Usern. Die Größenordnung von Facebook als Ganzes wird man wohl kaum erreichen können und schon gar nicht als kleines Startup oder als Einzelentwickler. Als Facebook Applikationsentwickler dagegen kann man mit wenig Aufwand viel erreichen und auf die Möglichkeiten eines riesigen Social Networks zurückgreifen.
Ist das in Deutschland ein Thema? Hab mal gegoogelt und nur eine Handvoll Facebook Apps gefunden, die mir eher wie ein “Proof of Concept” aussahen (Qype, Jimdo etc.)…?
