ymc
› Trimediales Kinderportal - Zambo startet in Web, TV und Radio
Die drei Vektoren der SRG (Schweizer Fernsehen, Radio und die dazugehörigen Onlineangebote) weisen medientypische Stärken auf:
- Das Radio hat kurze Produktionswege und somit hohe Aktualität.
- Das Fernsehen hat mit Abstand die grösste Reichweite.
- Das Internet besticht durch neue Interaktionsmöglichkeiten.
http://www.zambo.ch markiert nun den Auftakt der Konvergenzstrategie. Das trimediale Gemeinschaftsprojekt von Schweizer Fernsehen und Schweizer Radio DRS realisiert erstmals das Konzept einer vollständig konvergenten Redaktion. Hinter den fünf Moderatoren steht eine integrierte TV-, Radio- und Onlineredaktion, die das medienübergreifende Kinderprogramm aus einem eigens gebauten Studio heraus betreut.
Neu war auch die Projektstrategie: Erstmals war nicht das Online-Konzept aus bestehenden Sendeformaten zu entwickeln, sondern umgekehrt: Corporate Identity und Studiodesign folgten der Online-Gestaltung. Die drei Medienformen sollten zu einer einheitlichen Welt verschmelzen.
Projektstart war im Dezember 2009. Zur konzeptionellen Beratung, Gestaltung, sowie zur Umsetzung von HTML, CSS und vor allem Flash wurde die Berliner Agentur Gosub ausgewählt. Gosub brachte erhebliche konzeptionelle Erfahrung mit Kinderwebsites mit und gab dem "Weltenkonzept" sein Gesicht.
Die Zeitvorgabe war fixiert: Launch der Plattform am 16. August, Sendestart am 30. August 2010. Auf diese Termine waren auch der Studiobau und die Neustrukturierung der Redaktion abgestimmt, eine Verschiebung somit ausgeschlossen.
Projektmethodik: Für Softwareprojekte mit fixem Termin und erst noch zu erarbeitender Ausgestaltung empfiehlt sich ein iteratives, agiles Vorgehen. Scrum ist ein Vorgehensmodell zur Produktentwicklung nach den Prinzipien der lean production. Es basiert auf der Erkenntnis, dass von der relevanten Information zu Projektbeginn nur minimale Ausschnitte verfügbar sind. Das Projektteam lernt also kontinuierlich hinzu.
Scrum integriert diesen Lernprozess über Anforderungen, Rahmenbedingungen und technische Machbarkeiten in die Produktentwicklung. Es zielt auf ein maximales Verhältnis zwischen dem Wert des Endprodukts und den investierten Ressourcen. Deshalb ist in Scrum alles verboten, was die Produktivität hemmt. Dies gilt insbesondere für schriftliche Gesamtspezifikationen, deren Nutzen offensichtlich begrenzt ist, weil bekanntlich kaum ein Projekt am Ende so aussieht, wie zu Beginn vorgesehen.
Das Team soll in der Lage sein, auf die sich wandelnde Sachlage stets so flexibel wie möglich, eben "agil" reagieren zu können. Es erhält hierfür von der Geschäftsleitung als Vorgabe nur eine schriftliche Vision des Vorhabens, die ihm erklärt, zu welchem Zweck das Produkt entwickelt werden soll. Soweit bereits einzelne Funktionen favorisiert sind, erfolgt das Briefing in Form von Userstories.
Deren konkrete Ausgestaltung, insbesondere der technischen Aspekte, erarbeitet das Team schrittweise selbst, und setzt sie anschliessend sofort um. So entsteht früh ein testbarer Prototyp. Spätere Teilspezifikationen greifen auf Projekterfahrung mit allen Arbeitsschritten, vom Wireframe bis zum Deployment zurück, was bei Fixpreisprojekten im Wasserfallmodell nicht möglich ist. Ein weiterer Vorteil liegt in der Kostenkontrolle: Die Gesamtfunktionalität kann in gleich aufwändige Pakete unteteilt werden. Nur das erste wird beauftragt. So hat das Management Gelegenheit, die Auftragsformulierung für den nächsten sogenannten "Sprint" anhand eines bereits funktionalen Prototypen zu überprüfen.
Die Scrum-Philosophie wurde von YMC auf die organisationalen Gegebenheiten angepasst. Ein erfahrener Projektleiter des Kunden übernahm die Rolle des Product Owners. YMC stellte den Scrum Master. Das Projektteam wurde aus Vertretern von Fernsehen, Radio, interner Gestaltung, interner IT sowie den ausführenden Mitarbeitern der Lieferanten gebildet. Zwar mussten sich die Beteiligten zunächst an das ungewohnte Vorgehen gewöhnen, Unsicherheiten überwinden, und im Team eine gemeinsame Arbeitskultur entwickeln. Schon bald aber empfanden sie den intensiven persönlichen Austausch zwischen publizistischer, gestalterischer und technischer Perspektive einhellig als sehr fruchtbar.
Tatsächlich hatte das Team am 16.8. ein ausgereiftes Portal realisiert, welches fristgerecht in Produktion ging. Die in den ersten Tagen aufgedeckten Bugs waren so minim, dass bis zum Ende des Folgesprints, also zwei Wochen später, auf Deployments verzichtet werden konnte. Die Redaktion begann zu arbeiten, und das technische Team konnte sich auf das zweite Release konzentrieren.
Die mit Zambo auslaufende Radio-Community www.pirando.ch war bereits kommunikativ auf den Umzug vorbereitet. Per Klick migrierten in den ersten Tagen über 300 Kinder ihre Blogs von Pirando zu Zambo. Neues Gefäss bildet ein gemeinsames Blog, der Treff. Dessen Beiträge, aber auch jede redaktionelle Seite können die Kinder kommentieren. Ein eigenes Wissensangebot (Zambothek), spielerische Anwendungen sowie das Streaming-Archiv vergangener Fernseh- und Radiosendungen runden das Angebot ab.
Programmatisch umfasst Zambo: Kinder-Alltagsthemen, Hörspiele, fiktionale Geschichten (Zambox), Quizzes wie Song oder Gong? oder Zambooster, ein kindgerechtes Magazin für gesellschaftliche und politische Themen (Zamboskop) und ein Musikmagazin, das von den Kindern massgeblich selbst gestaltet wird (ZamboCharts). Als besondere Identifikationsfigur begleitet der Berner Freestyle-Wortakrobat Knackeboul das Programm. Auch er ist nicht einfach nur "auf Sendung": Knackeboul reiht sich in den Dialog zwischen Redaktion und Publikum ein, indem er über Themen rappt, welche die Kinder ihm vorgeben.
Die Rückkanäle Internet und Telefon werden weitreichend genutzt. Zu Programmzeiten chatten die Kinder in der Plauderbox mit den Redaktoren und nehmen so Einfluss auf das Programm. Gleichzeitig startete die erste Schweizer Kinderserie, Best Friends", deren Online-Auftritt in Zambo integriert ist.
Die sensible Zielgruppe erforderte ein besonderes Sicherheitskonzept: Neue Benutzer werden von der Redaktion telefonisch verifiziert. Auch die Eltern müssen zustimmen, sie erhalten einen Leitfaden für Betreuung ihrer Kinder bei der Internetnutzung.
Auf dem Portal selbst bleiben die Kinder anonym. Sie werden auch nicht mit Foto dargestellt, sondern mit einem von Gosub liebevoll gestalteten, von den Kindern veränderbaren Flash-Avartar. Die Redaktion moderiert und kontrolliert die Community. Das Sicherheitskonzept wurde in Zusammenarbeit mit der Schweizerischen Kriminalprävention der kantonalen Polizeibehörden (SKPPS) entwickelt.
eZ Publish bildet die Schnittstelle zwischen den drei Medien. Es ist Frontend für Live-Streaming und Videoarchiv, liefert Audio-Podcasts aus und verwaltet Content, Benutzerprofile und Avartar-Konfigurationen. Im Backend stehen ein massgeschneiderte Publikationsworkflow und ein CRM-Tool für den Telefonsupport zur Verfügung. Eine 3D-Engine im Fernsehstudio wird mit der Avartar-Konfiguration beliefert, so dass die von den Kindern in der Avartar-Werkstatt gestalteten Figuren regelmässig animiniert im Fernsehen auftreten.
Das Team hat den Sprintzyklus beibehalten, launcht also alle zwei Wochen neue Funktionalität. Inzwischen bearbeitet es Userstories im Bereich Social Networking. Hierbei geht es um eine kindgerechte Vereinfachung, und um eine positive und lehrreiche Medienerfahrung.
Zambo wird auf SF zwei und DRS 1 gesendet und ist als iTunes-Podcast erhältlich.
derick rethans
› Collecting Garbage: PHP's take on variables
Collecting Garbage: PHP's take on variables
This is the first part of three-parts column that was originally published in the April 2009 issues of php|architect.
In this three part column I will explain the merits of the new Garbage Collection (also known as GC) mechanism that is part of PHP 5.3. Before we start with the intricate details of PHP's new GC engine I will explain why it is actually needed. This, combined with an introduction how PHP deals with variables in general is explained in this first part of the column. The second part will cover the solution and some notes on the GC mechanism itself, and the third part covers some implications of the GC mechanism, as well as some benchmarks. But now first on to the introduction.
PHP stores variables in containers called a "zval". A zval container contains besides the variable's type and value, also two additional bits of information. The first one is called "is_ref" and contains a boolean value whether this variable is part of a "reference set". With this bit PHP's engine knows how to differentiate between normal variables, and references. However, PHP has user-land references—as created by the & operator, but also an internal reference counting mechanism to optimize memory usage. The second piece of additional information, called "refcount", contains how many variables names—also called symbols—point to this one zval container. All symbols are stored in a symbol table, of which there is one per scope. There is a scope for the main script (ie, the one requested through the browser), as well as for every function or method.
A zval container is created when a new variable is created with a constant value, such as:
$a = "new string";
In this case the new symbol name "a" is created in the current scope, and a new variable container is created with type "string", value "new string". The "is_ref" bit is by default set to "false" because no user-land reference has been created. The "refcount" is set to "1" as there is only one symbol that makes use if this variable container. Also, if the "refcount" is "1", "is_ref" is always "false". If you have Xdebug installed you can display this information by calling:
xdebug_debug_zval('a');
which displays:
a: (refcount=1, is_ref=0)='new string'
Assigning this variable to another variable name, increases the refcount:
$a = "new string"; $b = $a; xdebug_debug_zval( 'a' );
which displays:
a: (refcount=2, is_ref=0)='new string'
The refcount is "2" here, because the same variable container is linked with both "a" and "b". PHP is smart enough not to copy the actual variable container when it is not necessary. Variable containers get destroyed when the "refcount" reaches zero. The "refcount" gets decreased by one for each symbol linked to the variable container leaves the scope (f.e. if the function ends) or when unset() is called on a symbol. The following example shows that:
$a = "new string"; $c = $b = $a; xdebug_debug_zval( 'a' ); unset( $b, $c ); xdebug_debug_zval( 'a' );
which displays:
a: (refcount=3, is_ref=0)='new string' a: (refcount=1, is_ref=0)='new string'
If we now call "unset( $a );" the variable container, including the type and value will be removed from memory.
Things get a tad more complex with compound types such as arrays and objects. Instead of a scalar value, arrays and objects store their properties in a symbol table of their own. This means that the following example creates three zval containers:
$a = array( 'meaning' => 'life', 'number' => 42 ); xdebug_debug_zval( 'a' );
which displays (after formatting):
a: (refcount=1, is_ref=0)=array (
'meaning' => (refcount=1, is_ref=0)='life',
'number' => (refcount=1, is_ref=0)=42
)
Graphically, it looks like:
You can see the three zval containers here: "a", "meaning" and "number". Similar rules apply for increasing and decreasing "refcounts". Below we add another element to the array, and set it's value to the contains of an already existing element:
$a = array( 'meaning' => 'life', 'number' => 42 ); $a['life'] = $a['meaning']; xdebug_debug_zval( 'a' );
which displays (after formatting):
a: (refcount=1, is_ref=0)=array (
'meaning' => (refcount=2, is_ref=0)='life',
'number' => (refcount=1, is_ref=0)=42,
'life' => (refcount=2, is_ref=0)='life'
)
Graphically, it looks like:
From the above we see that both the old and new array element now point to a zval container which "refcount" is "2". Of course there are now two zval containers, but they are the same one. The xdebug_debug_zval() function does not show this, but could by also displaying the memory pointer. Removing an element from the array is like removing a symbol from a scope. By doing so, the "refcount" of a container that an array element points to is decreased. Again when the "refcount" reaches zero, the variable container is removed from memory. Again an example to show this:
$a = array( 'meaning' => 'life', 'number' => 42 ); $a['life'] = $a['meaning']; unset( $a['meaning'], $a['number'] ); xdebug_debug_zval( 'a' );
which displays (after formatting):
a: (refcount=1, is_ref=0)=array (
'life' => (refcount=1, is_ref=0)='life'
)
Now, things get interesting if we add the array itself as an element of the array, which we do in the next example—in which I also sneaked in an reference operator as otherwise PHP would create a copy here:
$a = array( 'one' ); $a[] =& $a; xdebug_debug_zval( 'a' );
which displays (after formatting):
a: (refcount=2, is_ref=1)=array (
0 => (refcount=1, is_ref=0)='one',
1 => (refcount=2, is_ref=1)=...
)
Graphically, it looks like:
You can see that the array variable ("a") as well as the second element ("1") now point to a variable container that has a "refcount" of "2". The "..." in the display above shows that there is recursion involved, which of course in this case it means that the "..." points back to the original array.
Just like before, unsetting a variable removes the symbol, and the reference count of the variable container it points to is decreased by one. So if we unset variable $a after running the above code, the reference count of the variable container that $a and element "1" point to gets decreased by one, from "2" to "1". This can be represented like:
(refcount=1, is_ref=1)=array (
0 => (refcount=1, is_ref=0)='one',
1 => (refcount=1, is_ref=1)=...
)
Graphically, it looks like:
Although there is no symbol in any scope pointing to this structure anymore, it can not be cleaned up either because the array element "1" still points to this same array. Because there is no external symbol pointing to it, there is no way for a user to clean up this structure anymore, and thus you get a memory leak. Fortunately, PHP will clean up this data structure at the end of the request, but before then this is taking up valuable space in memory. The mentioned situation happens often if you're implementing parsing algorithms or other things where you have a child point back at a "parent" element. The same situation can also happen with objects of course, where it actually happens easier as objects are always implicitly used by reference.
This might not be a problem if this only happens once or twice, but if there is thousands, or even millions of these memory losses, this obviously starts being a problem. Especially in long running scripts, such as daemons where the request basically never ends, or in large sets of unit tests. The latter caused problems for us while running the unit tests for the Template component of the eZ Components library. In some cases it would require over 2 GiB of memory, which our test server didn't quite have.
With that we conclude this introduction, for more information on how PHP deals with variables I can point you at June 2005 issue of php|architect. That article is also available on-line as PDF (http://derickrethans.nl/files/phparch-php-variables-article.pdf). In the next installment, we're going to discuss the solution to the memory leak problem with circular references.