Die Technik bei Pro7’s “Keep Your Light Shining” – ein Kommentar

Gleich 2 deutsche TV-Sender haben in diesem Monat neue TV-Formate an den Start gebracht. Was so besonders daran ist? Sie binden die TV-Zuschauer überaus interaktiv und umfangreich über das Internet in’s Geschehen der Sendung ein.

Zum einen war da das Quizduell. Die ARD hatte den Vortritt… und hat gleich mal in’s Klo gegriffen. “Ein Hackerangriff”, so hieß es, habe die Server lahmgelegt. Im Nachhinein ist allerdings gar nicht so klar, ob es sich nicht doch nur um die zu erwartende hohe Last einer TV-Livesendung gehandelt hat. Besonders zu betonen ist allerdings, dass alle Beteiligten den Fail sportlich und mit Humor genommen haben. So kann ich jemandem einen solchen Fehltritt auch gerne verzeihen, ist ja schließlich alles #Neuland 😉 Etwa eine Woche später war dann technisch alles behoben und die Show konnte wie geplant mit Beteiligung der Internet-Nutzer stattfinden.

Heute waren dann die privaten Sender an der Reihe. Vertreten durch Pro7 mit der Musik-Show “Keep Your Light Shining”. Aus Spaß und Neugier habe ich heute tatsächlich mal eine app an mein Facebook-Profil gelassen und per Browser mitgemacht.

Ich war von der Technik von Anfang an begeistert. Wie die Entwickler es hinbekommen haben, die Web-Applikation so synchron zum TV-Bild zu halten ist wirklich bemerkenswert. Die Show funktioniert so: Es wird in jeder Runde ein Lied gesungen. Von allen Kandidaten abwechselnd, im 30-Sekunden Takt. Die Webseite aktualisierte bei jedem Kandiaten-Wechsel die Anzeige entsprechend… und das, zumindest für mich, fast auf die Sekunde genau synchron zum TV-Bild. Komplett in HTML5, ganz ohne Audio-Watermarking und sogar ohne WebSockets.

Da ich in dem Bereich ja kein ganz unbeschriebenes Blatt bin, habe ich mir während der Sendung die von Pro7 eingesetzte Technik mal etwas genauer angeschaut und ein paar best practices abgeleitet 🙂

Als View-Layer wurde Facebook’s React eingesetzt. Damit wurde die Mechanik der Applikation größtenteils im Voraus in JavaScript programmiert. Eine JSON Konfigurations-Datei hat der Applikation die Kandidaten der Woche mit allen Details wie Name, Bilder usw. mitgeteilt (so muss nur diese eine Datei für die nächste Episode der Sendung ausgetauscht werden). Es sind also in erster Linie eine handvoll statischer Resourcen involviert gewesen: die kleine HTML-Datei, React selbst, die KYLS-JavaScript-Applikation, die JSON Kandidaten-Konfiguration, ein bisschen CSS und ein paar Bilder wurden via Amazon’s CloudFront verteilt. Durch dieses hochperformante CDN ist das Ausliefern der statischen Resourcen kein Problem.

Bleibt noch die Synchronisation und das tatsächliche Voting.

Die Synchronisation wurde, soweit ich das beurteilen konnte, durch “stinknormales” 10-Sekündiges Polling realisiert. Zu erwähnen ist hier, dass beim Polling auf jedes Byte geachtet wurde: Übertragen wurde ein JSON-Objekt mit ein-buchstabigen keys und nur numerischen IDs und arrays als Werten. Das JSON Polling übermittelt den Stand der Sendung (aktuelle Runde, wer in dieser Runde noch drin ist, wer gerade singt,…) an die React Applikation. Was hier auf Serverseite verwendet wurde, kann ich natürlich nicht wissen. Ich weiss nur, dass sich als Webserver ein “Apache” gemeldet hat, und dass auch bei dieser Applikation auf Amazon’s Cloud gesetzt wurde. Per DNS RoundRobin kamen gut drei Dutzend Amazon-Server rein (danach habe ich mit Anfragen aufgehört ;)) – die Cloud halt. Mich würde aber wirklich interessieren, was hier serverseitig für die Persistenz bzw. als Datenstore genommen wurde…

Das Voting, also Daumen-Hoch oder Daumen-Runter Clicks, wurde, ähnlich wie das Polling, mit einem eigenständigen XMLHttpRequest an die Amazon-Server realisiert. Dieser beinhaltete die Runde und die Kandidaten-ID als URL Parameter. Ich vermute, die eindeutige User-ID (vom Facebook-Konto) war in irgendeiner Form in den Cookies enthalten. Keine Magie, alles straight forward.

Fazit: so viel wie möglich statisch machen, möglichst kein dynamisches HTML auf Serverseite rendern sondern JS-Client-Libraries wie React verwenden, den statischen Content cachen und auf CDN’s setzen, skalierbare Applikationsserver (zB Amazon’s Cloud) für Interaktionen verwenden, bei Live-Updating/Polling jedes Byte sparen.

Mir hat die Sendung jedenfalls aus technischer Sicht, Spaß gemacht! Ich bin gespannt was für Internet-Formate sich die Sender weiterhin so ausdenken, was davon technisch hinhaut, und wie es gebaut sein wird 🙂

Advertisement

Stop the domain parking madness!

Parked WebsiteF that… I came up with a cool idea for a Web2.0 project while taking a shower yesterday. Now I’m looking for a cool name, I came up with a bunch of good ones (like 5 or so), which is unusual for me. So it is even more frustrating that every single domain I tried is parked! That’s right: not just taken, I would be ok with that, but parked.

For those of you who don’t know what domain parking is, it’s basically registering a domain “just in case”, “for future use” or “just to own it” but not putting any real content on it. Service providers like GoDaddy even offer putting ads on such domains so that whoever registered them can earn money. While that might sound like a funny method to earn money, the side effects are huge.

Flash forward to 2015…

I have about 350 domains. That’s not a problem since they only cost 20 cents a year.

My buddy has been hired as “domaineer” by a local toiletbrush seller, he’s registering internet domain names for them all day long “so they own them… just in case”.

Google and the W3C announced that they will introduce a new HTTP status code: 40404. It makes perfect sense since a “this domain is parked” is way more likely than a “page not found”. Status code 404 has been deprecated.

Seriously <insert name of internet organization having the autohority to forbid domain parking>, DO SOMETHING AGAINST IT!

Update: W00t! Finally found one 🙂 More infos later (might take a while since it’s an in-my-spare-time project)…

Microsoft gives early x-mas gift to Web developers!

I just got my early x-mas gift from Microsoft. No, it’s not an Xbox360 (which would have been great as well). Actually, it came to me in form of a link in an iChat window… a link to an msdn blog:

Internet Explorer 8 passed ACID2 test!

To me, this is the best Microsoft news for whole freaking 2007. I have been hoping for this since I left the “3-column-table-design” pattern some years ago. IE7 was already slightly a bit better than IE6 (yeh, png transparency is great), but it still sucked when it came to the standards.

To you Microsoft, let me say this: if IE8 is available for free (and by that I mean no genuine advantage stuff) on XP and upwards and if it renders my XHTML/CSS standard code without extra-IE-patches, I swear I’m gonna block IE6/IE7 from even trying to view the sites, with an appropriate IE8 download link note of course. So be sure you’ll get my IE8-pushing support if you do well!

Sure, it’s been overdue but nevertheless, this news is epic… I’m happy for the rest of my day now, cheers 🙂