– Hjelp, vi skal drive med sånn datastøtta greier!

Robotene er her! Om ikke som T-800 / T-850 i første omgang, så i alle fall i hakket mer interessante former enn de robotene som jobber i store produksjonshaller rundt omkring i verden.

Robotene jeg tenker på er eksempelvis en app som henter værdata for stedet du befinner deg, automatisk skrevne sportsnyheter eller en tjeneste som bruker tilgjengelige data på nye måter.

Det robotene ofte gjør, er å ta over de oppgavene som er repetetive og grusomt kjedelige å gjøre manuelt, i alle fall når du gjør dem for tredje og fjerde gang. De kan også brukes til oppgaver som er så kompliserte at det er vanskelig å gjennomføre dem feilfritt om man skal gjøre dem manuelt.

Datamateriale og datakilder

En gjennomsnittlig dum robot, en som ikke er utstyrt med all verden av intelligens og kreativitet, trenger noe å jobbe med – et datamateriale. Hva dette datamaterialet består av, er helt avhengig av hva du ønsker at roboten din skal levere.

Vil du lage en robot som automatisk finner frem til nye filmer som passer din filmsmak, trenger du tilgang til lister over filmer som snart er klar for lansering og en profil som definerer filmsmaken din. Her trenger du altså to datakilder. Datamaterialet kan for eksempel bestå av tittel, lanseringsdato, sjanger, språk, skuespillere og synopsis. Du kan ha en forkjærlighet for bestemte sjangere, språk eller skuespillere – eller det kan være relevant å presentere noen eller alle disse opplysningene i sluttproduktet.

Å legge inn alle filmer som kommer manuelt er en nitidig oppgave, og ødelegger egentlig hele poenget med å ha en robot som gjør jobben for deg. Men for et mindre, begrenset datastøttet prosjekt, hvor det bare er interessant med en begrenset datamengde, kan det jo selvfølgelig være en løsning.

Men det er godt mulig at det allerede finnes en datakilde som inneholder dataene du ønsker. Noen av disse må du betale for å få tilgang til, mens andre er åpent tilgjengelige – med noen begrensninger, for eksempel i hvor mye data du kan hente ut eller hvor mange spørringer du kan gjøre mot databasen. Det er ofte også begrensinger i hvilke format du får hentet ut dataene i. Men mer om det senere.

Av og til kan dataene du ønsker bare være tilgjengelige som en del av en nettside, hvor det tilsynelatende er umulig å bruke dataene som kilde. Da kan du bygge deg en scraper, som henter hele nettsiden, analyserer innholdet og henter ut de dataene du ønsker å bruke. Her er det mange potensielle fallgruver. Du er avhengig av en god nettside med konsekvent markup. Desto bedre oppbygd den er, desto enklere vil det være å hente ut data. En måte å hente ut data på fra en nettside, er å benytte XPath for å hente ut data fra bestemte tags i markup’en. Det fordrer lett at det du leter etter befinner seg på samme sted, eller er kodet likt, hver gang. En annen måte å hente ut data på, er å bruke regulære uttrykk (Regular Expressions – RegEx). Da kan du hente ut data basert på kontekst istedet for plassering i markup, noe som kan gjøre det enklere å hente ut data som er mer flyktig i plasseringen.

En ulempe med webscraping er at det er tidkrevende. I alle fall sett opp mot datauttrekk fra en database eller andre åpne datakilder. Dersom du må benytte deg av en webscraper i prosjektet ditt, anbefaler jeg deg at du lagrer resultatet i din egen database. Når du så skal hente ut og presentere dataene senere, vil denne prosessen fremstå som øyeblikkelig.

Bearbeiding av datamaterialet

Ideen du hadde til prosjektet ditt, hvilke data du ønsket å presentere og hvordan du ønsket å presentere dem, samsvarer kanskje ikke alltid med det datamaterialet du har tilgjengelig. Eller – om vi trekker fram ideen om en robot som finner frem til nye filmer som passer din filmsmak – du har flere datakilder å forholde deg til.

Nå begynner jobben med å kombinere, sortere og trekke ut de dataene du ønsker. Hvordan du gjør dette, er avhengig av flere tekniske faktorer. Hva slags datakilde er det? Kan du kjøre spørringer mot datakilden? I hvilket miljø opererer roboten din, er den et frittstående program (app, Python etc), er den en dynamisk nettside (.net, PHP, JSP etc) eller er det en enkel nettside hvor alt foregår front-end (Javascript)?

Står du selv for datakilde og datamateriale, kan du jo legge til rette for den videre bruken fra begynnelsen av – og alt går som en lek. Om du må forholde deg til data fra en ekstern kilde, er du gitt de føringene de legger. Jo mindre samsvar det er mellom de føringene de eksterne kildene legger og sluttresultatet du ønsker, desto mer arbeid blir det i bearbeidingen av datamaterialet.

Jo mer og komplisert bearbeidingen av datamaterialet, desto mer avhengig er du av å ha kraftig datakapasitet tilgjengelig. Du bør med andre ord vurdere å håndtere bearbeidingen av datamaterialet i et mellomlager på en server et sted enn på en liten mobiltelefon, om det er på en mobiltelefon du skal presentere dataene.

Grensesnittene fra datakilde til endelig plattform vil i tillegg til føringer fra datakilden også være påvirket av hvilken plattform du skal presentere på. En vanlig måte å utveksle data på i dag, er via REST. Ofte skjer datautvekslingen i XML eller JSON-format. Dersom datautvekslingen skjer i en enkel nettside, altså front-end, og datakilden er lokalisert på en annen server enn nettsiden, er det vanlig å sende data i JSONP-formatet for å omgå Same Origin-begrensningene i nettleserne. Resultatet blir da levert som et Javascript-objekt, som kan bearbeides videre i koden før den presenteres.

Hvordan få til lesbare data?

I sin enkleste form er data bare et sett med tabeller, men for folk flest kanskje vanskelig å tyde. For å se sammenhenger er det enklere om dataene presenteres visuelt.

Også her er, som tidligere i prosessen, gir den tekniske plattformen føringer for hvordan du kan løse det. Felles for dem alle er uansett muligheten for å bruke ferdige kode-biblioteker som letter arbeidet betraktelig. Her er det selvfølgelig en avveiing om biblioteket er for stort og tungt sett opp mot til hva du skal presentere. Det er også en avveiing om biblioteket er kompatibelt med enheten det skal presenteres på. Det hjelper lite om biblioteket letter deg for flere dagers arbeid om bare en promille av målgruppen din får sett det. Slik fragmentering har man hatt innen webutvikling i alle år, med ulik støtte i ulike nettlesere. Nå ser man det i større og større grad også innen app-utvikling.

Det finnes selvfølgelig også en del ferdigpakker, hvor alt man har å gjøre er å mate inn dataene. Her er man gitt den presentasjonen ferdigpakken gir, og har i liten grad mulighet til å påvirke presentasjonen.

Sånn sett står du mye friere i presentasjonen desto mer av koden du er villig til å utvikle selv. Selv har jeg veldig sansen for en middelvei med bruk av bibliotek, som nevnt over. D3 er et fantastisk Javascript-bibliotek som gir deg veldig mange muligheter til å bygge opp din presentasjon akkurat slik du vil ha den. Det er dog noe komplisert å sette seg inn i.

Geolokaliserte data er kan være spennende å visualisere på et kart. Her har jeg god erfaring med å bruke Javascript-biblioteket Leaflet. Her vil mange kanskje argumentere for Google Maps sitt API. Google har en del begresninger knyttet til bruken, samt at det har en kostnad. Både Leaflet og Google Maps kan benyttes med oppdaterte kart fra Kartverket helt gratis.

Egentlig er det bare fantasien som setter begrensningene. Og ressursene. Og deadline.

Det eneste som ikke finnes, er den store, røde knappen som gir deg det du vil ha med en gang. Det ligger noen timers jobb bak en slik presentasjon.

Publisert 20.5.2016 16.00