NRK har fått med seg at kidsa sitter med laptopen på fanget når de ser på tv, og at de twitrer og chatter om det de ser. De ønsker naturlig nok å trekke kidsa nærmere seg ved å være tilstede der kidsa (også) er — på nettet.

Prosjekleder Andreas Wiik på “NRK Nye Medier” hadde fått oppgaven: På en liten måned skulle han ha en fullt brukbar chatte-tjeneste på nett, med innebygd markedsføring. NRK ønsker altså å bygge et stykke software der kidsa — og eventuelle andre som føler seg kallet til en intim chattestund fokusert på en enkelt tv-sending — naturlig vil samles for å kommentere det stygge håret til tv-verten, eller oppfordre andre til å stemme på sin favoritt, eller hva-enn-kidsa-bestemmer-seg-for-å-gjøre med en fokusert chatte-tjeneste.

Hvordan lager du en fungerende Facebook chatte-applikasjon på 20 arbeidsager? Desember 2009?

Som en første iterasjon av et større prosjekt, ville prosjektleder Andreas Wiik  kjapt bygge en tjeneste som kapitaliserte på en eksisterende brukergruppe  så den kunne “go viral” — altså spres ved at folk forteller hverandre om den. Han ville lage en TV-prat applikasjon som kunne spres virtuelt via folks vennelister. Andreas samler tre konsulenter fra tre forskjellige selskaper, får opp en utviklingsserver og alt som hører til, og kjører en slags mini-scrum med ukeslange sprinter. Og lykkes. Ved første Melodi Grand Prix delfinale legges linken til facebook-applikasjonen ut på NRKbeta, og 250 brukere signer opp og begynner å chatte.

Bevisst bruk av åpne løsninger

En slik kjapp utvikling hadde ikke vært mulig uten et bevisst fokus på å bruke eksisterende, åpne løsninger. Istedenfor å utvikle kruttet på nytt, legges all tid og energi inn på å skape bare akkurat det som er nytt ved den nye softwaren. En Openfire chat-sever ble brukt som underliggende chatte-teknologi. Denne implementerer den åpne XMPP-standarden (også kjent under det mer sexy navnet Jabber). XMPP er en xml-standard for både gruppe- og direktemeldinger, og for såkalte “presence”-meldinger; slike som forteller vennene dine at du er “online” eller “idle” eller “out fishing”. For å bygge opp slike xml-strenger som følger XMPP-standarden, slik at vi kunne sende dem fra brukernes nettlesere til Openfire-serveren, benyttet vi Jack Moffitt’s Strophe-bibliotek. Dette er et deilig javascript-bibliotek som brukes til å bygge XMPP-xml, og som i tillegg tar seg av å sette opp en BOSH-forbindelse til serveren,og gir oss hendelser fra serveren på et gullfat. Strophe kan derimot ikke brukes til å tolke xml’en som kommer fra Openfire-serveren. Men til det passet jQuery som hånd-i-hanske.

Masters of Glue

Når teknologiene allerede er laget, hva gjør programmereren i prosjektet? På mange måter kan vi si at programmererens oppgave blir å lime eksisterende teknologier sammen; han lager litt logikk for å lime sammen brukerhåndteringen til Facebook og OpenFire, litt logikk for å bestemme hvordan OpenFire-chattemeldinger skal vises i browseren, litt logikk som bestemmer hvordan brukeren skal kunne interagere med den nye applikasjonen. Det kan kanskje høres ut som om programmererens rolle nedtones. Det kan være fristende å sette inn nyutdannede, rimeligere “ressurser” i et slikt arbeid. I praksis bør du tenke deg om en gang til før du iverksetter en slik taktikk. Hvorfor? Fordi det å raskt sette seg inn i forskjellige APIer er det samme som å raskt sette seg inn i andre programmereres tankesett. Og det krever erfaring.

Eksisterende teknologier + Erfarne programmerere = Rask utvikling av nye produkter

Hvordan er det mulig å lage en fullt fungerende, testklar viral chatte-applikasjon på en måned? Svar: ved å “leverage” eksisterende teknologier, og få erfarne programmerere til å sette dem sammen, samt lage de manglende bitene. På 20 dager har vi ikke laget et perfekt produkt, det er fremdeles noen feil og mangler. Men på kun en liten måned har vi laget et produkt som kan vises frem og brukes. De første brukerne vil kunne komme med tilbakemeldinger og dermed være med på å forme det videre produktet slik at det blir noe de kunne tenke seg å bruke på lengre sikt. På den måten kan du sikre at du ikke bruker lang tid og mye penger på å utvikle et produkt det til slutt viser seg at ingen vil ha.