Neulich standen wir bei einem größeren PHP Projekt, das auf dem Zend-Framework basiert, vor der Aufgabe, die Systeme so einzurichten, daß eine flexible Releaseplanung möglich wurde. Die übliche Trennung in Live, Staging und Developmentsystem und das SVN Repository reichten nicht mehr aus, weil die Anforderungen gestiegen waren.
Die oberste Priorität bei dem Projekt ist Stabilität. Gleichzeitig hagelt es aber ununterbrochen Sonderwünsche von verschiedenen Fachabteilungen. Der einfache entwickeln-testen-livestellen Workflow genügt so nicht. Was ist also zu tun?
Wir entschieden uns, das Projekt grundsätzlich in einen Entwicklungszweig (devel) und einen stabilen Produktionszweig (stable) zu teilen. Dementsprechend gibt es für den Stable-Branch die übliche Devel-Staging-Live Umgebung. In diesem Zweig werden ausschlißelich Bugfixes gepflegt, während Funktionsänderungen und Ergänzungen ausschließlich in dem Devel-Zweig vorgenommen werden, in dem jeder Entwickler einen eigenen Arbeitsbereich hat.
Das ist zwar schon besser, löst aber noch nicht die Problematik mit den Anforderungen der Fachabteilungen, die häufig nicht auf ein neues Major Release warten wollen oder können. Also haben wir die bisherige Applikation in Fachanwendungen und gemeinsam genutzte Basisfunktionen geteilt. Nun stellte sich die Frage, wie man das bei einer Zend FW-basierten Anwendung macht und wie die Versionsverwaltung dafür aussehen kann. Schließlich liegen alle Controller in einem Verzeichnis, alle Models in einem Verzeichnis und alle Views ebenfalls in einem Verzeichnis.
Refactoring
Die Lösung ist, alle Controller einer Fachanwendung in ein eigenes Unterverzeichnis zu packen und dasselbe mit den Models und den Views zu tun. Dementsprechend ändert sich selbstverständlich die Benamung von Dateien, Klassen und URLs. Ein fiktives Beispiel:
Der Controller ‘Abrechnung‘ gehört zur Fachanwendung ‘Bestellungen’. Nun lag also bisher im Verzeichnis ‘application/controllers/‘ die Datei ‘AbrechnungController.php‘ mit der Klasse ‘AbrechnungController‘. Die URL lautete dementsprechend ‘http://servername/abrechnung/‘.
Nach dem Umbau liegt die Datei ‘AbrechnungController.php‘ in dem Verzeichnis ‘application/controllers/Bestellungen‘ und die Klasse heißt nunmehr ‘Bestellungen_AbrechnungController‘. Die URL ist daher nun ‘http://servername/bestellungen_abrechnung/‘.
Versionskontrolle
Da nun die einzelnen Applikationteile getrennt sind, können sie jeweils in separate Subversion Repositories gepflegt werden. Genauer gesagt, gibt es weiterhin nur eines, das aber wie folgt eingerichtet wird: Im Repository gibt es für jeden Applikationsteil (Basis und Fachanwendungen) ein eigenes Unterverzeichnis. Innerhalb dieses Unterverzeichnisses folgt die üblich Einteilung in ‘trunk’ (Hauptzweig), ‘branches’ (Release) und ‘tags’. Das sieht dann ungefähr so aus:
repos/
base/
branches/
tags/
trunk/
bestellungen/
branches/
tags/
trunk/
rechnungswesen/
branches/
tags/
trunk/
Ein Release ist nun ein Branch von ‘base’ in das bestimmte Releases der jeweiligen Fachaanwendungen per svn:external eingebunden wird. Es ist also bspw. möglich, eine Version 1.2 mit ‘Bestellungen 0.7’ und ‘Rechnungswesen 1.4’ zusammenzustellen.
In den nächsten Wochen wird sich zeigen, ob die Praxis hält, was wir uns in der Theorie so schön ausgedacht haben.
Obwohl ich selbst seit mehr als zwei Jahren bei diesem Microblogging/Groupmessaging Zeug mitbaue und mitmache, ist mein Verhältnis dennoch etwas ambivalent.
Einerseits halte ich solche Tools prinzipiell für genial, weil sie meiner Meinung nach ein tatsächlich vorhandenens Kommunikationsbedürfnis auf einfache Art befriedigen.
Andererseits kommt es immer darauf an, was die Menschen draus machen. Das ist aber genau der Knackpunkt. Und das war auch schon das Problem bei Newsgroups und E-Mail: Zwei Dienste, die man heutzutage kaum noch vernünftig benutzen kann.
Michael Seemann hat auf seinem Blog vor einiger Zeit eine “nur” emotional begründete Kritik vorgebracht: “Twitter stinkt!“. Die Kritik halte ich trotzdem für relevant, weil Emotionalität in Kommunikationsfragen über hopp oder top entscheiden kann. Jetzt hat er aber auch noch eine sachlich begründete Kritik geschrieben: “Das Ende von Twitter“.
Die Kernthese ist: Twitter ist eine “Sendeblase”: “niemand hört irgendwem noch zu. Jedenfalls tendentiell.”
Wie jedes Medium das eine relavante Reichweite erreicht hat, wird nun auch twitter von Neugierigen und Geschäftemachern vereinnahmt und zunehmend missbraucht. Das kann die Idee zerstören, noch bevor sie bei dem breiten Publikum überhaupt angekommen ist.
Cem Basman hat vor ein paar Tagen auf seiner Seite zur Microblogging Conference die folgende Behauptung aufgestellt:
“Ein Tweet hat etwa die Lebensdauer von 5 Minuten“.
Das ist nicht falsch, allerdings auch nicht die ganze Wahrheit, wie ich selbst festgestellt habe.
Das Schöne daran, wenn man seinen eigenen Microblogging-Service (www.zzap.de) nutzt, ist daß man genau die Features einbauen kann, die einem wichtig sind. Neben der Unterstützung von Handies und Fotos nutze ich eigene Shortlinks um beispielsweise auf neue Blogeinträge hinzuweisen und nicht externe Dienste wie tinyurl. Das ermöglicht mir, eigene Statistiken aufzustellen.
Ursprünglich hatte ich nämlich vor, die Nachrichten nach zwei oder drei Wochen zu löschen. Ich war davon ausgegangen, daß Nachrichten nur ein bis zwei Stunden aktuell sind und nach einer gewissen Frist nicht mehr gelesen werden. Tatsächlich ist das aber nicht so. Ich habe für meine eigenen Kurznachrichten folgendes festgestellt:
- Gemessen an der Anzahl meiner Follower habe ich sehr viele Leser des Originalartikels. 50% und mehr sind keine Seltenheit.
- Die ersten Leser habe ich in der Regel bereits in der ersten Minute nach Veröffentlichung.
- Die meisten Leser habe ich innerhalb der ersten 10 Minuten
- Es kommen allerdings auch nach Wochen oder Monaten noch Leute auf den Artikel. Eine Artikel vom 04.11.09 hatte den letzten Leser am 04.03.09
- Mittlerweile nutzen einige Leser mobile Endgeräte wie iPhone oder normale Handys
Für das Maketing relevant sind m.E. tatsächlich bestenfalls die ersten 60 Minuten mit einem klaren Peak in den ersten 5. Allerdings scheinen die Zugriffe nie völlig abzuebben. Die Verteilung sieht dann so ähnlich aus, wie bei dem Artikel “Aus dem Leben eines Stubentweets” auf live.hackr. Nur daß es einen sehr langen – äh – “long tail” gibt.
Ich bin gerade wieder mal über einen Artikel gestolpert, in dem gekürzte RSS-Feeds gegeißelt werden. Die vielen Kommentare stoßen alle in dasselbe Horn: gekürzte RSS-Feeds stinken.
Hmmm…
Obwohl mein Feed nicht stinkt – bin ich wirklich der Einzige, der das anders sieht? Im Gegenteil – oftmal nerven mich Volltext-Feeds so richtig. Ein absolutes Negativbeispiel ist in meinen Augen Techrunch. Nicht nur daß der Feed werbeverseucht ist. Die Artikel beinhalten auch noch Bilder und sind oftmals extrem lang.
Hey – wenn ich das will, rufe ich lieber die Website auf, weil die nicht so ein beschissenes Layout bietet, wie mein Feedreader.
Wozu sollten Feeds denn eigentlich gut sein? In meinen Augen sollten sie einen schnellen Überblick über viele Artikel aus vielen verschiedenen Quellen bieten. Wenn mich einer interessiert, klicke ich auf den Link und bekomme den vollständigen Artikel mit allem Tschingderassabum, wie Bildern, Videos und natürlich auch Werbung, die die Site refinanziert.
Volltextfeeds versauen die Übersichtlichkeit und funktionieren mit eingebetteten Medien nicht in mobilen Endgeräten. Aussagekräftige Teaser sind meines Erachtens wesentlich sinnvoller.
Es kann wirklich niemand guten Gewissens sagen, er hätte die heutige Situation auf dem Zeitungsmarkt nicht kommen sehen, ohne gleichzeitig zuzugeben, fast 30 Jahre im geistigen Tiefschlaf gelegen zu haben. Hier ist der Beweis: Eine Reportage aus dem Jahr 1981 über ein Experiment des San Francisco Examiner.
Im direkten Vergleich die heutige Website des SF Examiner.
Heute feiere ich ein kleines Jubiläum: meinen 500. Blogartikel. WOW! Das hätte ich mir nicht träumen lassen, als ich Mitte 2006 mit dem Bloggen angefangen habe. Eigentlich wollte ich damals nur ein paar Freunde und Komilitonen auf dem Laufenden halten, während ich meine Diplomarbeit vorbereitet habe. Es sollte “irgendwas mit Handies oder so” werden. Daher auch der Untertitel “tiny little gizmos”. Wir sind doch alle in unsere kleinen elektronischen Spielzeuge vernarrt, oder? Diesen Artikel schreibe ich ja auch gerade auf meinem Mini-Notebook während ich im Zug sitze.
Das Diplom habe ich Anfang 2007 dann auch problemlos bekommen. Da mir das Bloggen tatsächlich richtig Spass gemacht hat, wollte ich danach nicht einfach so sang- und klanglos wieder damit aufhören. Der thematische Schwerpunkt hat sich zwar ein bischen verschoben, aber es ist ein reines Hobbyprojekt geblieben. Mehrere Angebote für Werbung auf meiner Seite habe ich abgelehnt. Ich schreibe nur über Sachen, die mich bewegen und zwar genau so, wie mir der Schnabel gewachsen ist. Auf die geschätzten €2,45 pro Monat kann ich da getrost verzichten. Aber genug der Vorrede.
Freibier! Oder noch besser: freie Software!
Zur Feier des Tages gebe ich heute einen aus – und zwar einen Download ;-)
Mein Diplomthema war “mobile community” und seit Anfang 2006 entwickle ich auch an einer dementsprechenden Software: zzap. Mittlerweile ist die Software in der 4. Version angekommen und ich habe mich dazu entschlossen, zzap als Open Source unter der GPL freizugeben. Seit heute gibt es die Version 0.4.148 zum Download. Eine kurze Aufzählung der Features von zzap:
- Multichannel – Unterstützung von Web, iPhone und normalen Handies.
- Multilanguage – Deutsch und Englisch sind serienmäßig. Weitere Sprachen sind leicht hinzuzufügen.
- Connectivity – Einbindung in Blog und twitter möglich.
- Enhanced Content – Kurznachrichten plus Links plus Fotos.
- Easy Setup – Ein Installationsscript hilft beim Einrichten der Software.
- Extendable – Erweiterungsfähig durch Plug-in Architektur.
- Multitier, Schichtentrennung, MVC oder wie das jetzt gerade heisst. Bei meiner Software ist Ablaufsteuerung, Datenzugriff und Ausgabe jedenfalls ordentlich getrennt.
Würde mich freuen, wenn der Eine oder Andere die Software mal ausprobiert. Feedback ist allerherzlichst willkommen. Bei Interesse lasse ich mich auch gerne in Gespräche auf der MBC09 (Micro Blogging Conference) verwickeln.
Download: zzap V0.4.148 (376 KB)
Ich bin kein Freund von geschlossenen Communitysystemen. StudiVZ hat mich von Anfang an abgeschreckt. Das Vorbild Facebook nervt mich aber mindestens genauso. Ich habe auch damals mit dem Cycosmos wenig anfangen können. Mich stören vor allem zwei Dinge:
- Die explizite und implizite Profilierung der Nutzer, die Grundlage des Geschäftsmodells ist.
- Leute, die überwiegend innerhalb dieser Walled Gardens kommunizieren sind kaum noch zu erreichen, wenn man nicht selber Mitglied ist.
Als ich darübe ein wenig nachdachte, fiel mir auf, daß wir mittlerweile auf der 4. Evolutionsstufe der Virtual Communities angelangt sind – und daß es sicherlich eine weitere Entwicklung geben wird. Von daher habe ich Hoffnung, daß doch noch alles gut wird. ;-)
Die Frage ist nun, wie die nächste Evolutionsstufe aussehen kann. Im Fokus meiner Betrachtung stehen hier übrigens ‘normale’ private Nutzer und nicht Organisationen, die über viele Ressourcen verfügen. Daher ist das Internet in dieser Betrachtung auch erst ab Mitte der 90er Jahre von Interesse.
Stufe 0: Direkter Informationsaustausch (seit Ende der 70er Jahre)
Besitzer der ersten Heimcomputer wollten einen schnellen und einfachen Austausch von Informationen und Daten zwischen Computern an räumlich entfernten Orten. Sie nutzten dazu die Datenfernübertragung per Modem über das Telefonnetz.
Positiv:
Effizienter Austausch zwischen zwei Systemen.
Negativ:
Da per Telefon immer nur eine 1:1 Verbindung zustande kommen kann, wird es schwierig, wenn sich mehrere Menschen austauschen wollen. Es ist einfach nicht praktikabel, alle Kommunikationspartner nacheinander zu verbinden.
Stufe 1: Geschlossene Gruppen (80er Jahre)
Um diesen Nachteil auszugleichen, entstanden geschlossene Systeme mit einem zentralen Hub. Die möglichen Kommunikationswege werden dadurch erheblich vereinfacht. Jeder Kommunikationspartner stellt nur noch eine Verbindung zu dem Zentralsystem her, die er im Anschluss an den Datenaustausch wieder abbricht. Die Verteilung der Information unter den verschiedenen Teilnehmern übernimmt das Zentralsystem. Es gab viele unterschiedliche Arten dieser Systeme; staatliche (BTX, Minitel, Prestel), kommerzielle (Compuserve, AOL) und enorm viele private Mailboxen.
Positiv:
Eine einfache Kommunikation zwischen allen Teilnehmern, die an dem Zentralsystem angemeldet sind
Negativ:
Es war keine Kommunikation zwischen den Teilnehmern unterschiedlicher Systeme möglich. Ein BTX-Nutzer konnte z.B. keine Nachricht an einen Nutzer von Compuserve oder einer privaten Mailbox schicken.
Stufe 2: Vernetzte Gruppen (ca. 1985-1995)
Um den automatisch Austausch von Informationen unter den verschiedenen Mailboxen zu ermöglichen, wurden spezielle Protokolle und Vorgehensweisen entwickelt. Das größte und bekannteste so entstandene Netzwerk war das sogenannte FidoNet das in seinen besten Zeiten aus über 35.000 Mailboxen auf der ganzen Welt bestand.
Positiv:
Kommunikation über Länder- und Systemgrenzen hinweg war nunmehr relativ einfach möglich.
Negativ:
Es gab nur eine beschränkte Anzahl von Diensten, man arbeitete im Prinzip noch immer die meiste Zeit offline und die komplette Kommunikation verlief ausschließlich textbasiert.
Stufe 3: Internet – die völlige Offenheit (seit ca. 1995)
Mit der prinzipiellen Verfügbarkeit des Internet verlor das Fidonet schnell an Bedeutung. An die Stelle der überschaubaren Mailbox trat nun ein recht anonymer Zugangsprovider. Im Internet hat jeder Zugriff auf alle frei verfügbaren Ressourcen.
Positiv:
Sofortiger Zugriff auf alle verfügbaren Dienste. Grafische Benutzeroberflächen, wie das WWW, Multimediainhalte usw.
Negativ:
Kein Stallgeruch mehr. Viele Mailboxuser fühlten sich im fast grenzenlosen Cyberspace etwas verloren. Es kann auch von Nachteil sein, für jeden erreichbar zu sein (Spam).
Stufe 4: Geschlossene Communities im offenen Internet (seit ca. 2002)
Geschlossene Communities gab es zwar schon seit Mitte der 90er Jahre, aber einen richtigen Boom gab es erst nach 2002 mit Myspace und Facebook und Businesscommunities wie Xing und LinkedIn.
Positiv:
Man findet schneller gleichgesinnte oder interessante Leute.
Negativ:
Es sind wieder geschlossene Systeme, die keinen echten Austausch mit Usern in anderen Communities ermöglichen.
Der nächste Schritt: Offene Communities (ab 2009?)
Der nächste logische Schritt besteht m.E. eigentlich in einer Vernetzung kleiner und mittlerer Communities. Das wird den Investoren von Myspace, Facebook, StudiVZ und anderen zwar nicht schmecken, aber ich gehe davon aus, daß diese Entwicklung kommt – mit oder ohne sie. Die ersten Anzeichen, wie OpenID und OAuth existieren ja bereits. Im Gegensatz zum völlig offenen Internet wird hier allerdings die Frage der Zugriffsrechte zentral werden. Welchen Teil meiner Daten zeige ich nur meinen Freunden, welchen Teil speziellen Gruppen und was ist öffentlich? Die Kontrolle darüber muß auf jeden Fall in den Händen der Nutzer liegen.
Positiv:
Man bleibt so im Regelfall “unter sich”, ist aber trotzdem global erreichbar. Man behält die Kontrolle über die eigene Erreichbarkeit.
Negativ:
Tja?
Fragen…
Sollte dazu möglicherweise die Idee der Mailbox als “Heimatsystem” eine Renaissance erleben? Die eigene “Kuschelecke” im kalten Netz? Sollte man dazu Standardsoftware schaffen, damit jeder einfach ein solches System für seine kleine Interessengruppe gründen kann? So eine Art “WordPress” für Communities?
Twitter kommt nicht so recht aus den Schlagzeilen. Kaum haben sie es geschafft, daß ihr Service endlich stabil läuft, schon tauschen sie ihren CEO aus (twitterblog: Meet Our CEO and Chairman, Again). Grüchteweise ziehen die Investoren jetzt die Daumenschrauben an, weil twitter noch immer kein einleuchtendes Geschäftsmodell vorweisen kann. Das sieht auch der Kommentator Dave auf Techchrunch so: “Future company that will go bankrupt because it lacks a biz plan.“.
Es besteht also durchaus die Möglichkeit, daß twitter demnächst von der Bildfläche verschwindet. (Nicole, schreib schnell Dein Buch zu Ende!) Umso wichtiger scheint nun die Etablierung eines microblogging- bzw. micromessaging standards. Wie gut, daß bereits an sowas gearbeitet wird.
Aber es geht ja nicht nur um twitter – man muß das große Bild sehen: Jetzt geht das große Aufräumen im Silicon Valley los.
Vor einigen Tagen machte bereits eine Präsentation von Sequoia Capital die Runde, in dem ihre Investments unmissverständlich aufgefordert wurden, sich endlich um das Geldverdienen zu kümmern, wenn sie nicht rausgeschmissen werden wollen (“Get real or go home” auf slide 54). Den Investments von anderen VCs wird es vermutlich ähnlich ergehen. Das ist unbequem für die Betroffenen, aber immerhin gibt es Sequoia noch. Es ist davon auszugehen, daß länsgt nicht jeder VC überlebt.
Was bedeutet das für Internetunternehmen?
Darüber wird in den einschlägigen Kreise zur Zeit diskutiert. Einige sehen schwarz, andere begrüßen die Marktbereinigung. Ich selber sehe das so:
Die Zeit des Rumspielens ist vorbei. Ohne funktionierendes Geschäftsmodell, Kunden und genügend Rücklagen braucht man momentan nicht zu gründen. Damit gelten im Valley plötzlich dieselben Reglen, wie auch überall sonst auf der Welt. Das “Reality-distorsion-field” über der Bay-Area ist fürs Erste ausgeschaltet. Das sind m.E. gute Nachrichten für Gründer in anderen Teilen der Welt. Sie müssen nicht mehr befürchten von einem amerikanischen Konkurrenten an die Wand gedrückt zu werden, bloß weil dieser gerade eine $20 mio Finanzierungsrunde hinter sich hat. Gründen ist schwierig. Das ist es jetzt und vorher war es das auch schon – zumindest wenn das Geschäftsmodell nicht aus einem angestrebten Exit bestand.
Zur Information: Hier sind nochmal die Slides von Sequoia Capital:
Gestern haben wir in der Firma eine Einführung in die ersten Module der neuen Open Source Groupware Tine 2.0 bekommen. Es ging dabei vornehmlich um die Adressverwaltung und die Einbindung in die Telefonanlage. Es sind zwar noch nicht alle Module voll funktionstüchtig, aber der Fortschritt ist unverkennbar. Es gab zum Projektbeginn durchaus unterschiedliche Meinungen zu Sinn oder Unsinn, so eine komplexe Software komplett neu zu entwickeln, aber mein Eindruck ist, daß sich der Schritt gelohnt hat.
Groupware?
Bei Tine 2.0 handelt es sich um eine sogenannte Groupware. Das ist Software, die die Organisation der Zusammenarbeit in Gruppen (z.B. in Firmen) unterstützt. So sind meist mindestens Funktionen für Kontaktlisten, Termin- und Aufgabenplanung vorhanden. Große Firmen verwenden dafür meist Microsoft Exchange oder Lotus Notes. Vielen kleinen Firmen ist das aber zu aufwändig und teuer. Sie nutzen stattdessen webbasierte Open Source Anwendungen, wie z.B. das seit einigen Jahren recht beliebte eGroupware.
Einfache Bedienung
Tine 2.0 nutzt moderne Komponenten (PHP5, Zend Framework, extJS) und basiert auf einer sauberen neu konzipierten Architektur – aber sowas interessiert ja nur uns Techis. ;-)
Für den normalen Anwender wesentlich wichtiger ist die hervorragende Bedienbarkeit. Hier erinnert nichts mehr an Websites. Fast alles fühlt sich so an, wie man es von normaler Software gewohnt ist, obwohl alles im Browser läuft. Kein nerviges Neuladen von Seiten – alles flutscht.
Wer auf der Suche nach einer entsprechenden Lösung ist und noch etwas Zeit bis zum Produktiveinsatz hat, sollte sich Tine 2.0 unbedingt einmal genauer anschauen. Bei uns in der Firma läuft die Software jedenfalls schon testweise parallel zur vorhandenen Lösung. Was ich selbst unheimlich praktisch und besonders finde, ist die Einbindung in unsere Telefonanlage. An Homeofficetagen von zuhause aus die Rufumleitung aktivieren zu können oder Anruflisten einsehen zu können, hat schon was.
Das Lustige an den ganzen aufkommenden Microblogging-, Messaging- und Lifestream Diensten ist die Frage, wie man alles unter einen Hut bekommt. Eigentlich muss jeder (Dienst) mit jedem anderen kommunizieren können. Für solche Aufgaben gibt es in der “echten” IT (Banken, Versicherungen usw…) richtig teure Middleware, z.B. von Tibco.
Und was machen wir armen Web2.0-Schmuddelkinder? Wir können jetzt auf Services wie Gnip zurückgreifen. Marco hatte mich neulich bei einer Recherche schon mal daruf hingewiesen, aber da war ich nicht so recht aufnahmefähig. Heute ist auf Golem dazu ein Artikel (“Gnip 2.0 verteilt Daten via Push in XMPP“) erschienen.
Mir stellt sich dabei natürlich wieder die Frage, ob ich Lust habe, alle meine Lifestream-Daten und die meiner Freunde über solch einen Dienst zu routen, der wie die Spinne im Netz sitzt und sich die ganzen leckeren Datenhäppchen anliefern lässt.
« Previous Page — Next Page »
