Dirk Ollmetzer | Monday, 17 September 2007 |
DevelopmentUm Webapplikationen zu bauen ist die Programmiersprache meiner Wahl bereits seit einigen Jahren PHP. Daran hat auch der gegenwärtige Hype um Ruby on Rails nichts geändert. Warum auch? Ich habe vor einiger Zeit geguckt, was es mit dem tollen MVC-Pattern (Model-View-Controller) auf sich hat, von dem plötzlich alle reden um dann festzustellen, daß ich selbst seit Jahren auf diese Weise Webapplikationen baue. PHP hat zudem mittlerweile eine Reife erreicht, das es für Enterprise Applikationen einsetzbar macht. Ruby hat da noch einen längeren Weg vor sich. Ich hörte von Problemen bei Deployment und Skalierung. Ich sehe also zunächst keinen Grund für mich, zu wechseln und bleibe bei PHP.
Trotzdem ist es Zeit für Neues!
Nachdem vor kurzem angekündigt wurde, Weiterentwicklung und Support für PHP4 einzustellen kommt nun endlich Schwung in den längst überfälligen Wechsel zu PHP5. Meine bisherigen Anwendungen habe ich -widerwillig- immer noch in PHP4 programmiert, weil mein Hoster einfach nicht umgestellt hat und ich keine Lust hatte, mit allen Domains umzuziehen.
Jetzt ist Schluss – die Bude wird komplettsaniert!
Den Wechsel nehme ich gleich zum Anlaß, eine einheitliche Codebasis für meine Anwendungen zu schaffen. Sie sind zwar alle vom Aufbau sehr ähnlich, aber eben nicht identisch. Ein modernes Framework muss her. Nachdem ich mir in letzter Zeit u.a. Cake, Symfony oder das Zend Framework angeschaut und für recht interessant befunden habe, entschloss ich mich dennoch dazu, ein eigenes zu entwickeln. Eigentlich bin ich kein Freund davon, das Rad 100 mal neu zu erfinden, aber es gibt einen gewichtigen Punkte, der dafür spricht: Meine bestehenden Anwendungen! Ein Refactoring ist zwar sinnvoll und überfällig, aber ich habe weder Zeit noch Lust, alles von 0 an neu zu schreiben.
Meine Anforderungen
- Wiederverwendbar, modular, objektorientiert
- Konsequente Nutzung von PHP5 und bewährten Libraries wie PEAR
- MVC-Pattern
- Suchmaschinenoptimierte URLs mit Fallback, fall kein rewrite möglich ist
- Browserausgabe mit XHTML und AJAX-Möglichkeit
- Unterstützung mobiler Endgeräte
- XML-basierte Ablaufsteuerung
Letzterem verdankt das Projekt seinen Arbeitstitel: Pipeline.
Bitte zu beachten: Das ist ein interner Projekttitel und steht somit keinesfalls irgendwie in Konkurenz zu evtl. bestehenden Namensrechten Dritter.
Auch wenn es sich vermutlich etwas hinziehen wird – ich werde in meinem Blog über den Fortgang des Projekts berichten.
Ich wurde schon häufiger gefragt, wie ich es hinbekomme, daß meine Webapplikationen (zumindest zzap und fastfiction) zwischen normalem Browser und Handy unterscheiden können und unterschiedliche, angepasste Inhalte ausliefern. Die Antwort lautet: mittels automatischer Geräteerkennung.
Leider gibt es nicht die eine Methode, mit der man ganz einfach abfragen kann, welche Eigenschaften das Gerät hat, sondern man muß sich einer Kombination unterschiedlicher Methoden bedienen. Die Methode, die ich für meine Projekte benutze ist mehrstufig.
Bei der Konzeption definiere ich zunächst die grundlegenden Geräteklassen, die unterstützt werden sollen. Jede dieser Geräteklassen wird später mit speziell angepasstem Content beliefert. Typische Vertreter sind ‘web’ (also normale Webseiten auf einem Computer), ‘wap1’ (Alte WAP-Telefone, WML-basiert. Mittlerweile zu vernachlässigen), ‘wap2’ (XHTML-basiert, farbig, von nahezu allen Handies der letzten 2 Jahre unterstützt) ‘imode’ (In Deutschland nicht sehr populär) und ‘pda’ (Windows mobile, Palm, evtl. Symbian). In der Regel konzipiere ich nur noch für zwei Klassen, nämlich ‘web’ und ‘wap2’.
Exkurs: Warum überhaupt noch für WAP entwickeln?
Ich höre immer häufiger, daß WAP tot sei, weil die tollen neuen Handies doch alle schon “richtige” Browser an Bord haben. Das mag für einige hochwertige Geräte stimmen, z.B. für mein Nokia E61, aber erstens sind diese Geräte noch nicht so zahlreich, zweitens fehlen noch immer wichtige Features, wie z.B. Flash-Unterstützung (z.B. für Videos), drittens ist selbst UMTS für “fette” HTML-Seiten zu langsam und viertens sind die Ein- und Ausgabemöglichkeiten prinzipbedingt extrem eingeschränkt.
Der wichtigste Punkt ist allerdings, daß normale Internetseiten einfach nicht den Anforderungen für eine mobile Anwendung entsprechen. Sie müssen schnell, übersichtlich und einfach sein, und den mobilen Nutzungskontext berücksichtigen (kurze Aufmerksamkeit, Ablenkung, etc.). Daher müssen mobile Web/Wapseiten auf das Wesentliche reduziert sein: Simple Navigationsstruktur, Content auf das Notwendigste reduziert, minimale Eingaben.
Wenn aber ohnehin schon die ganze Sitestruktur für mobile Nutzung angepasst werden muss, kann man die Inhalte auch gleich so ausliefern, daß sie auf mindestens 98% aller Mobiletelefone funktionieren.
Meine Strategie der Geräteerkennung zielt nun darauf ab, in der ersten Phase die Geräteklasse zu ermitteln und danach zu versuchen, die Daten für eine verfeinerte Anpassung zu ermitteln. Es ist stets eine Kombination von Grundannahmen und dem Versuch anschließend genaueres zu ermitteln. Die erste Grundannahme ist, daß der Client ein normaler Webbrowser ist. Dann wird im Useragent-String nach Hinweisen darauf gesucht, daß es sich um ein Mobiltelefon oder PDA handelt. Wie man das schnell und sauber hinbekommen kann, zeigt Andy Moore in dem Artikel “PHP to detect mobile phones“.
Falls ein Mobile-Client erkannt wurde, wird abschließend versucht, Details, wie Screengröße und unterstützte Medienformate zu ermitteln. Diese Ermittlung kann recht aufwändig sein und sollte nur einmal zu Beginn einer Session gemacht werden.
Wenn man dann weiß, was für ein Gerät man vor sich hat, kann man endlich mit der Erzeugung und Auslieferung des spezifischen Contents beginnen.
Weiterführende Links:
Frustriert über externe Entwicklungen, die man nicht beeinflussen kann.
Genervt von Fehleinschätzungen Fremder.
Irritiert durch harte, ehrliche Statements von Freunden.
Nachdenklich durch Infragestellen der eigenen Position.
Inspiriert durch Konzentration auf den eigenen USP.
Beruhigt durch das Entdecken neuer Möglichkeiten.
Okay – Absagen muss man wegstecken, aber eines will ich mal klarstellen:
zzap ist kein Twitter-Clone!
Als ich mit der Idee anfing, war Twitter völlig unbekannt. Leider hat mich die Diplomarbeit einige Monate gekostet. Man baut an einer tollen Idee und gerade wenn man soweit ist, damit an die Öffentlichkeit gehen zu können – Booom!!!
Da hat irgendein Ami mal wieder die Welt neu erfunden und alle anderen sind Nachmacher!
Hallo?
Es würde ja mal helfen, die beiden Dienste nebeneinander zu stellen:
Zzap leistet mehr als Twitter.
Zzap sieht anders aus.
Zzap hat ein Geschäftsmodell.
Man muss es nicht mögen. Man muss nicht dran glauben. Man kann es für überflüssig halten. Damit habe ich kein Problem.
Aber ich bin KEIN Nachmacher!
Vor zwei Jahren habe ich im Rahmen eines Projektes an der Uni einen Verlag für Handybücher durchgerechnet und einen Prototypen gebaut.
Vor zwei Wochen dachte ich mir: Warum unzählige Zeilen Code im Keller Staub ansetzen lassen?
Vor zwei Tagen war es dann soweit: Das Projekt fastfiction ging mit dem Motto “Kultur auf das Handy” online (http://www.fastfiction.de). Zunächst nur mit einer kleinen Auswahl gemeinfreier, klassischer Werke. Es geht mir – wie bei zzap – zunächst vor allem darum, Feedback zu sammeln.
fastfiction - Kultur auf das Handy
Wie funktioniert fastfiction?
- Man kann das gewünschte Handybuch in Form einer JAR-Datei auf den Rechner laden und von dort aus auf das Handy übertragen, oder
- Die Seite direkt mit dem Handybrowser aufrufen (http://wap.fastfiction.de) und das Handybuch per WAP installieren
Viel Spass beim Ausprobieren. Feedback ist wie immer gewünscht.
Es war einmal vor langer, langer Zeit;
Da begab es sich, daß der junge Dirk sein Tagewerk mit Stadtplanung verbrachte…
Genau gesagt habe ich Mitte der 90er mein Geld mit CAD-zeichnen verdient. Das Büro für das ich gearbeitet habe – urbanistica berlin – war vollständig mit Apple Macintosh ausgerüstet. Damals waren 100MHz und 40MB Arbeitsspeicher enorm! Apple stellte gerade von Motorola auf PowerPC-Prozessoren um und war Windows um Lichtjahre voraus.
Lang’ ists her!
Und jetzt bin ich über das hier gestolpert: Ein Macintosh-Simulator im Browser. Unglaublich, wozu manche Leute ihre Zeit und Energie aufwenden, aber ein schöner Retro-trip war es schon.
Klasse, wie cool und aufgeräumt Mac OS 7 damals war…
Heute möchte zwei nette neue Features für zzap vorstellen: Desktop Widget und Skype Integration.
Falls man den ganzen Tag am Computer sitzt und über die Aktivitäten der Freunde informiert werden möchte, muss man nun nicht mehr regelmäßig die zzap Website aufsuchen, sondern kann das zzap Desktop Widget nebenbei laufen lassen. Auch der eigene Status lässt sich so einfach und schnell nebenbei aktualisieren. wie das aussieht zeigt die Abbildung auf der rechten Seite.
zzap Desktop Widget
Mehr Information zum Widget ist auf zzap zu finden.
Die Skype Integration ist ebenfalls für die Arbeit am Computer gadacht. Ein Blick auf das Profil eines Freundes zeigt, ob er mit Skype online ist (siehe Abbildung unten). Falls ja, kann mit einem Klick ein Anruf oder das Chatfenster geöffnet werden.
zzap / Skype Integration
Auch hier steht eine ausführliche Information auf zzap.
Die Arbeit an zzap (wer es noch nicht kennt: http://demo.zzap.de) schreitet voran. Das Kernprodukt steht im Wesentlichen. Jetzt fehlen die “bells and whistles”, wie englischsprachige Mitmenschen so schön sagen. Das ganze Drumrum, das eine Anwendung nett macht. Zum Beispiel die Integration in bestehende Apllikationen.
Bis jetzt habe ich nur Google Maps und Flickr integriert. Was wären weitere sinnvolle Services? Facebook, bzw. StudiVZ? Das unvermeidliche MySpace? Sevenload? Was noch?
Spätestens hier kommt man an einen Punkt, wo die Integration wirklich absolut lästig und zeitaufwändig wird. Nicht jeder hat eine API (z.B. Sevenload) und falls doch, ist diese garantiert komplett anders aufgebaut, wie die des nächsten Services. Zudem stellt sich die Frage, welche Services zzap selbst zur Verfügung stellen soll. Was soll die API leisten, wie soll sie aussehen?
Das Problem ist nicht nur mir aufgefallen. Rolf Skyberg (eBay) schreibt schreibt in seinem Blog, daß die Zeit für Standards im Bereich social Networks gekommen ist. Dem kann man uneingeschränkt zustimmen. Bloß: welche sollten das sein? Was sollen sie leisten?
Ein toller Ansatz um Benutzerkonten auf verschiedenen Systemen zusammenzuführen, ist OpenID. Aber hier wird auch ein Riesenproblem deutlich: Vertrauen.
Wie kann ich als Servicebtreiber garantieren, daß jemand mit einem OpenID-Account keinen Schindluder mit den andern Kunden treibt? Immerhin bin als Betreiber einem erheblichen juristischem Risiko ausgesetzt. Falls das jetzt “zu Deutsch” klingt: die gegenwärtige Rechtssprechung (die ich für absolut hahnebüchen halte) kann ich mir leider nicht aussuchen.
Die Entwicklung einheitlicher Standards im Bereich sozialer Netzwerke berührt also mehrere thematische Bereiche:
- Leistungsumfang der Schnittstelle
- technische Implementierung
- juristische Implikationen
Ich bin mal gespannt, was sich da so in nächster Zeit tut.
Auch in den letzten Tagen ging die Arbeit an zzap weiter.
Neue Features
- Integrierter Flickr-Badge bei Orten (per Tags) und bei Profilen (per Benutzername)
- Die Handynummer wird jetzt in eigenem Profil angezeigt, bleibt aber für die anderen unsichtbar
- Newsteaser auf der Startseite
- Eigene Videoseite
- Das Profil Foto wird nach dem Hochladen automatisch skaliert
- Anzeige, welche Freunde sich benachrichtigen lassen
- Benachrichtigung bei einer Kontaktanfrage funktioniert jetzt
Korrekturen und behobene Fehler
- Beschränkung des Eingabefeldes auf 160 Zeichen
- Leere Eingaben werden nicht mehr akzeptiert
- “Freunde Deiner Freunde”: Nutzer wird nicht mehr angezeigt, wenn bereits eine Kontaktanfrage vorliegt
- Benachrichtigungsmails kommen jetzt vom eigenen Account -> Besser für Spamfilter
Das waren noch Zeiten, als man 8-Bit Heimcomputer in Maschinensprache programmieren musste, damit man überhaupt irgendwas sinnvolles mit dem Gerät anstellen kann. Das habe ich damals auch gemacht. Mit dem Commodore 64 in 6502 Assembler.
Heutzutage läuft das ganz entspannt im Webbrowser per Javascript. Wahnsinn!
« Previous Page — Next Page »