Wenn jetzt sogar schon im ÖR Fernsehen von der Demoszene berichtet wird, kann ich nicht zurückstehen. Ich kann zwar nicht von der Evoke, der Breakpoint oder auf einer anderen Veranstaltung berichten – wozu auch? Das ist nicht mein Metier. Aber ich möchte hier eines meiner Lieblingswerke vorstellen: Masagin von Farbrausch und Neuro.
[Dieses Video wurde entfernt – *grrrr*]
Das Video bietet natürlich vergleichsweise schlechte Qualität. Um die Werke in voller Pracht genießen zu können, muss man sie allerdings als Programm auf seinem Rechner laufen lassen – so war es ja urspünglich auch gedacht. Wer nicht weiß, wovon ich schreibe, den möchte ich auf diesen Artikel auf Wikipedia hinweisen: Demoszene.
Die Programme von Farbrausch bekommt man hier: http://www.farb-rausch.com/productions.php
Pieter hat vorhin den Link auf eine Liste mit Grundsätzen für das Web-Projektmanagement getwittert. Die dort gesammelten Regeln sind einfach nur wahr! Zum Beispiel diese hier:
“The first 90% of the code accounts for the first 90% of the development time. The remaining 10% of the code accounts for the other 90% of the development time.“
Web Design & website Development Laws
WOW, das ist fix! Cem Basman hat heute morgen in seinem Blog die Frage “Zeit für ein MicroBlogging Camp? MicroBlogging Congress?” aufgeworfen. Das Feedback ist beeindruckend und nach wenigen Stunden war klar, daß so eine Veranstaltung offenbar dringend gewünscht wird.
So soll es also sein, und das Ding hat auch gleich einen Namen bekommen: MBC09 – Microblogging Conference 2009 und der Macher von identi.ca, Evan Prodromou, wird vermutlich auch anwesend sein. Daumen hoch dafür!
Werde mich vermutlich auch anmelden und ich hoffe, daß bis dahin zzap auch richtig läuft rennt. ;-)
Heute habe ich mit dem aktuellen Bugfix für zzap ein kleines Jubiläum erreicht: Revision 100 für die aktuelle Version steht im Subversion Repository. Dafür, daß ich noch überwiegend alleine und nebenbei programmiere ist das nicht schlecht. Aber es geht weiter. Es fehlen noch zwei Features und dann werde ich den Code veröffentlichen.
Dirk Ollmetzer | Wednesday, 13 August 2008 |
DevelopmentFür die Programmierer unter Euch:
Ein dicker Nachteil übertriebener Objektorientierung bei Webapplikationen besteht m.E. darin, daß sowohl in der Eingabe, als auch in der Ausgabe von HTTP/HTML basierten Anwendungen ja keine Objekte verwendet werden, sondern lediglich Name-Wert Paare, bzw Text.
Es muss also immer immer ein umständliches Mapping auf Objekte stattfinden. Ich erwarte eigentlich, daß ein Model entsprechende Arrays entgegen nimmt und zurückliefert und den Datenzugriff kapselt. Nebenbei bemerkt, werden die Daten in einer relationalen Datenbank ja schließlich auch nicht objektorientiert gespeichert. Es muss also gleich zweimal ein Objektmapping stattfinden: Einmal beim Lesen aus der Datenbank in die Objekte und dann wieder rückwärts beim Rendern des Views.
Das macht echt keinen Sinn. Wollte ich nur mal eben loswerden.
Bis zum ersten Alpha-Release ist es nun nicht mehr weit. Wirklich!
Die letzte noch ausstehende Funktion habe ich heute implementiert. Der twitter Export ist seit heute um einen twitter Import ergänzt. Wenn nun eine Nachricht an zzap schicke, wird diese sowohl an meinen twitteraccount geschickt und ich sehe die neuen tweets meiner Twitterkontakte.
Nun gilt in Feature-freeze; ich baue keine neuen Funktionen mehr ein, sondern kümmere mich nur noch um Fehlersuche. Einige Fehler sind auch bereits behoben:
- Einige UTF-8 Probleme behoben.
- Kleinere Korrekturen an Handy und iPhone-Version
- Kleinere Korrekturen, um Notices in den Logfiles zu unterbinden
Heute Abend habe ich angefangen zzap komplett auf UTF-8 umzustellen. Anlass dafür war die voranschreitende Integration von twitter. Bereits seit etlichen Wochen ist die Exportfunktion von zzap nach twitter funktionstüchtig. Meine Nachrichten in der twitter timeline schreibe ich bereits seit längerem per zzap.
Nun wurde es Zeit, auch den umgekehrten Weg zu beschreiten und eingehende twitternachrichten in zzap zu integrieren. Dieser Punkt ist deutlich kniffeliger, als der Export. Die Personen, denen ich auf twitter folge sind zunächst einmal keine Mitglieder auf zzap. Daher habe ich die userbase um “foreign users” erweitert. Das sind Personen, die auf anderen Systemen registriert sind, keine Mitglieder bei zzap sind, aber von denen Assets im System vorhanden sind.
Foreign Users sind daran zu erkennen, daß ihr Host mit im Namen aufgeführt wird. Während ‘dollmetzer’ also ein echter zzap-nutzer ist ( ;-) ), kann man bei ‘NicoleSimon@twitter’ gleich erkennen, daß es sich um einen Import von twitter handelt. Daran hängen natürlich noch etliche Details, wie die unterschiedliche Behandlung von Profildaten, Kontakten, MessageIds, Timestamps usw.
Ich habe die Änderungen noch nicht auf dem Livesystem, da ich noch ein paar kleinere Bugs beheben muss, aber es geht voran.
Stay tuned!
(So, ich gehe jetzt mal in die Koje. Nicht daß ich morgen wieder unfreiwillig Homeoffice machen muss.)
Ich bin ein Mann der goldenen Mitte. Extreme liegen mir nicht so. Auch nicht beim Programmieren.
Auf der einen extremen Seite der möglichen Umsetzung von Webapplikationen in PHP steht unübersichtlicher, verschwurbelter Spaghetticode. Nichts gegen Spaghetti auf dem Teller, aber bitte nicht im Computer.
Auf der anderen Seite finden sich komplett durchgestylte, mehrstufige, sauber abgeleitete Klassenhierarchien die auf bewährte Designpatterns zuzückgreifen. Das ist ganz toll – allerdings nicht für Webapplikationen in PHP. Das Problem dabei ist: Performance.
Ich bevorzuge Modularisierung, Wiederverwendbarkeit Schichtentrennung und so weiter. MVC ist dabei ne gute Idee, wenn auch nicht die einzig denkbare Option. Aber schlank muss es sein.
Komplexe Objekthierarchieen sind kein Problem, wenn sie compiliert und im Speicher gehalten werden. Bei PHP-Anwendungen ist das normalerweise nicht so. Bei jedem Request müssen diverse Dateien durch den PHP-Interpreter von der Festplatte geladen, übersetzt, initialisiert und ausgeführt werden – das dauert.
Zumal die Komplexität von “normalen” Programmen bei Webanwendungen in der Regel nicht gegeben ist. Keine Nebenläufigkeit, Events und ähnliches. Im Prinzip geht es immer um eine Abfolge mehrerer seperater Requests. Und jeder Request arbeitet eigentlich immer die folgenden Schritte ab: Eingabe, Verarbeitung, Ausgabe.
Es geht also um das rechte Maß. Soviel Trennung, Modularisierung und Abstraktion wie nötig – aber eben auch nicht mehr. Für zzap habe ich eine recht schlanke und dennoch flexible Lösung gefunden, denke ich.
Programmieren ist lustig und einfach. Zumindest im Vergleich zu den Fragen, die auftreten, wenn man die Software zu publizieren gedenkt. Aktuell schlage ich mich gerade mit der Frage herum, wie ich zzap lizensieren könnte. Open Source soll es sein – das ist schonmal klar. Aber welche der -zig Varianten kommt dafür in Frage? BSD, GPL (wenn ja, welche Version), LGPL, Affero ???
*puh*
In einem Papier des CCC vom Chaos Communications Congress 2004 wird der Charakter von GPL und BSD gut auf einen Punkt gebracht:
“GPL: Weitergabe ist erlaubt, Änderungen müssen weitergegeben werden; kompletter Quellcode muss auf Verlangen herausgegeben werden. (‘free speech’)
BSD: Weitergabe ist erlaubt, Änderungen müssen nicht weitergegeben werden; Quellcode muss nicht auf Verlangen herausgegeben werden. (‘free beer’)“
Feyrer, Hubert; GPL für Anfänger – Über Copyright, Lizenzen und den Schutz des geistigen Eigentums; S. 5
Für die GPL spricht, daß sie sogar schon von deutschen Gerichten im Prinzip anerkannt wurde. Die Frage ist, ob der virale Charakter (‘Alle abgeleiteten Werke müssen ebenfalls GPL lizensiert sein’) sinnvoll ist? Wenn nicht, wäre wohl die BSD-Lizenz vorzuziehen. So könnten abgeleitete Werke kommerziell verwertet werden. Aber will ich das? Die Affero Lizenz ist m.E.n. nicht sinnvoll für zzap. Wenn jemand mit zzap einen Service aufbaut und eigene Änderungen programmiert – wieso sollte ich ihn zwingen, diese ebenfalls offenzulegen?
So richtig einig bin ich mir noch nicht, aber ich tendiere zur Zeit zur GPL. Oder…?
Eigentlich isses ja ein bischen bescheuert: Fast niemand in Europa hat ein iPhone – warum sollte man dan auch noch zzap daran anpassen?
Vielleicht, weil ich auch ein bischen bescheuert bin? Oder neugierig? Oder weil ich einfach gerne mal neue Sachen ausprobiere? Oder weil ich damit die VC’s im Valley blenden will? Ich weiss es nicht.
Aber ich habe gestern mal ein wenig rumgespielt und habe eine Seite nutzbar gemacht. So langsam bekomme ich ein Gefühl für die Philosophie dahinter. Erinnert mich übrigens ein bischen an WAP1.1 mit den Decks. Hier sind es dann eben mehrere Listen in einem Dokument.
Online ist aber noch nix davon. Ich bin mir noch nicht sicher, wieviel Aufwand das wirklich wird. Wenn es lange dauert, lasse ich erstmal die Finger davon. Web/mobile/iPhone und dann noch in zwei Sprachen ist schon etwas Arbeit. Dabei fehlt momentan noch Funktionalität. Die ist eigentlich erstmal wichtiger.
Ich kann mich auch nicht dazu durchringen, die passende Hardware zum Testen zu besorgen – bei diesen besch…eidenen Vertragskonditionen, Netlock-Spielchen usw. Egal, ich behalte das mal im Auge. Ein Preview sieht übrigens so aus:
zzap iPhone Preview
« Previous Page — Next Page »