9. Mai 2008 von okiess
Ab nächste Woche Montag bin ich zwei Wochen in den USA und Kanada unterwegs. Ich werde nach San Francisco fliegen und von dort mit einem Mietwagen Richtung Norden fahren. Grobe Ziele auf der Route sind Portland, Seattle und Vancouver. Genauere Infos habe ich auf einer Google Maps Karte zusammengestellt. Ich werde sicherlich nicht alle Städte und Orte auf der Karte anfahren, daher sind einige Pins auf der Karte nur “Optionen”… ;).
Alle Einträge und Fotos vom Roadtrip findet ihr dann in der “Reisen” Kategorie dieses Blogs. Zudem werde ich dann und wann auch Twitter nutzen und von Zeit zu Zeit vermutlich auch mal ein Foto von unterwegs vom iPhone einschicken.
12. Februar 2008 von okiess
Ich habe heute endlich mein Macbook Air (plus Superdrive) bekommen… 
Ich hatte es drei Stunden nach der Macworld Ankündigung bestellt.
17. Januar 2008 von okiess
Mein Blog lässt sich nun auch auf einem iPhone bzw. iPod Touch betrachten… Wen es interessiert, findet hier ein Plugin und Theme für Wordpress.
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…
9. Dezember 2007 von okiess
Ein Feature von OSX Leopard, auf das ich sehr gewartet hatte, ist TimeMachine. Das Prinzip ist, dass man eine externe Festplatte anschließt und das ohne Aufwand sofort ein Backup des Systems erstellt wird. Es wird pro Stunde ein neues (inkrementelles) Backup erstellt, zudem ein tägliches und wöchentliches Backup solange bis die externe Platte voll ist (danach werden ältere Backups ersetzt).
Und genau dieser Zustand, dass die externe Platte voll ist, ist bei mir relativ schnell eingetreten (ich hatte eine 120GB 2,5 Zoll USB Platte benutzt). Ohne große Überlegungen habe ich mir dann eine neue 250GB Trekstor 2,5 Zoll Platte zugelegt. Diese kurzerhand mit dem MacOS Extended (Journal) Filesystem formatiert und los sollte es gehen… Aber direkt beim ersten Backup meines Macbook Pro 100GB ist das Backup gescheitert (nach etwa 10 GB gesicherten Daten). Das habe ich dann verschiedene Male wiederholt, immer mit dem selben Ergebnis: Backup gescheitert! Leider immer komplett ohne sinnvolle Fehlermeldung zur Analyse…
Nach einigem Googeln habe ich feststellen müssen, dass auch andere das Problem haben. Es wurde immer dazu geraten, die Festplatte mit einem neuen “Partitionstable” zu initialisieren. Meine Festplatte hatte den Aufkleber “Ready for Vista” auf der Verpackung, das hätte mir zu denken geben sollen… Nunja, man kann also eine Festplatte mit dem “Guid” Partitionstable (mit dem Festplattendienstprogramm) anlegen und damit soll es funktionieren…
Das Backup ist danach einiges weiter durchgelaufen, aber trotzdem immer gescheitert… Danach war ich es leid und habe mir eine weitere externe Platte (allerdings 3,5 Zoll mit 500GB) zugelegt, diese mit dem Guid Partitionstable ausgestattet und das Backup lief sofort durch… Hm, heisst das also, das meine 2,5 Zoll Festplatte “ready for Vista”, aber nicht “ready for Leopard” ist?
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…
28. Oktober 2007 von okiess
Ich habe am Freitag vormittag pünktlich meine vorbestellte Version von OSX 10.5 “Leopard” bekommen. Leider hatte ich keine Zeit es direkt zu installieren, so habe ich es mir am Samstag vorgenommen.
Da ich vorsichtig bin, habe ich zuerst einmal meine Zweitmaschine -ein schwarzes Core2Duo Macbook- migriert. Ich habe mich für die Variante “Neuinstallation” entschieden, da ich keinerlei wichtige Daten auf der Maschine hatte. Wie bei Apple üblich lief die Installation natürlich absolut rund und in etwa 30 Minuten hatte ich ein lauffähiges Leopard System.
Zuerst einmal habe ich die neuen Tools wie Time Machine, das neue iChat, Spaces und Safari 3.0 etc. ausprobiert, die alle einen guten Eindruck gemacht haben. Im Anschluss wollte ich die wesentliche Frage für mich klären: Kann ich unter Leopard an meinen derzeitigen Arbeitsprojekten arbeiten? Können alle benötigen Abhängigkeiten zum Laufen gebracht werden?
Nachdem ich ein Terminal Fenster geöffnet und die entsprechenden Befehle eingegeben habe, musste ich zu meiner Freude feststellen, dass Ruby 1.8.6, Rubygems und auch Rails 1.2.3 standardmässig vorhanden waren! Insgesamt sind 27 Rubygems vorinstalliert wie z.B. capistrano, fcgi, ferret und mongrel. Das sind schon einmal sehr gute Grundvoraussetzungen, allerdings benötige ich für die meisten meiner Arbeitsprojekte ImageMagick und rmagick.
Im nächsten Schritt habe ich dann mein Ruby Setupscript ausprobiert, über das ich auch schon mal geschrieben habe. Leider musste ich feststellen, dass sich ImageMagick mit Macports nicht installieren ließ. Es scheitert an der Abhängigkeiten “tiff” von ImageMagick (Auch GraphicsMagick hängt übrigens von “tiff” ab). Somit kann ich leider rmagick unter Leopard derzeit nicht zum Laufen bringen. Zudem ließ sich auch ruby ansich nicht kompilieren (zumindest ohne Patches oder spezielle Kompilieranweisungen), weder 1.84, noch 1.8.5 oder 1.8.6. Dann habe ich meine bereits kompilierten Binaries (ruby Versionen, ImageMagick, mysql5 etc.) von OSX Tiger herüber kopiert und konnte diese zum Großteil ausführen. Allerdings konnte ich mysql5 nicht zum Laufen bringen (mit sudo ausgeführt, konnte es sich angeblich nicht an den Port 3306 binden)…
Fazit: Ich persönlich kann meine Arbeitsmachine derzeit noch nicht auf OSX Leopard upgraden. Für Rails ansich ist OSX Leopard allerdings ein Riesenschritt nach vorne. Mit einer Standardinstallation von Leopard kann man sofort mit Rails loslegen. Die Abhängigkeiten, die mir derzeit noch Probleme bereiten, werden sicherlich auch bald von den entsprechenden Entwicklergemeinden gefixt oder Patches bereitgestellt. Also daher, bin ich noch ein bisschen geduldig…
Übrigens noch ein Hinweis für Java Entwickler. Java 6 ist nicht Teil von Leopard und die Java 6 Preview für Tiger läuft nicht unter Leopard! JDK 5 läuft allerdings problemlos.
Update: Nach einem frischen Macports Install habe ich nun mysql5 problemlos laufen. Auch das mysql gem habe ich installiert bekommen. Wenn ihr mysql5 mit macports installiert, könnt ihr folgenden gem Befehl verwenden:
ARCHFLAGS=”-arch i386″ gem install mysql — –with-mysql-include=/opt/local/include/mysql5/mysql/ –with-mysql-lib=/opt/local/lib/mysql5/mysql
Update 2: tiff kompiliert nun auch mit macports und somit kann ImageMagick problemlos installiert werden.
