Reduksjon i informasjonsmengden – bedre kvalitet og oversikt
Et av målene for opprydningen var en reduksjon i informasjonsmengden, slik at det er mulig å få bedre oversikt, både for redaktører og for besøkende på nettsiden. Det ble satt harde krav til hva slags informasjon som skulle kunne publiseres på de nye sidene. Samtidig ble webpublisering gjort mer sentralisert.

En ting som overrasket meg underveis i prosessen var hvor viktig de ulike avdelingene synes det var å få med mest mulig stoff om seg selv på de nye sidene. Underredaktørene la ned et betraktelig antall timer på telefon og e-post for å overbevise ansatte og beslutningstakere i organisasjonen om at all denne informasjonen ikke var like interessant for publikum. Kommunikasjonsjobben var minst like viktig som innholdsproduksjonsjobben.

Innholdsproduksjon tar tid
Innholdsproduksjon tar som regel lenger tid enn man tror. I følge innholdsstrategiguruen, Kristina Halvorssen er dette en svært hyppig årsak til at prosjekter blir forsinket. Arbeidet med innholdsproduksjon for Forsvaret.no var av avhengig av fagpersoner “ute i bruket”. Å samle inn webtekster, som skal være bedre enn de gamle, men mye kortere, er svært tidkrevende. Mange av tekstene ble derfor skrevet av redaksjonen og det ble flere runder med korrektur, sletting, godkjenning og omkalfatring før innholdet var klart til publisering.

Tusener av klikk spart
Utviklerkollegerne mine i Steria laget et smart script som gjorde at informasjonsstrukturen, som var laget i MindManager, ble importert i SharePoint og at sidene med tilhørende maler ble opprettet automatisk. Dette sparte webredaktørene utallige museklikk. Det var likevel ikke til å komme fra at publisering i SharePoint hadde sine utfordringer, spesielt i starten. Du kan lese mer om strukturgenerering i  presentasjonen SharePoint 2010 for Internet – Issues and solutions through a case study (Slideshare)  fra Norwegian Developer Conference tidligere i år.

Excel-oversikt og innholdsdugnad
En innholdsoversikt i Excel ble laget for de nye sidene. Kvalitet og eier av hvert innholdelement ble lagt inn. Dette var et godt oppfølgingverktøy for innholdsproduksjon i innspurten. Innhold ble skrevet på dugnad og det var mange bidragsytere.  

Forsvaret.no  var et kundedrevet prosjekt. Som konsulenter kunne vi dra videre til andre kunder da prosjektperioden var overstått. Forsvarets  webredaktør uttalte ved lansering at “det er nå arbeidet begynner”. Du, som er opptatt av webting, har kanskje oppdaget at Forsvaret.no har en helt tradisjonell venstremeny. Det er flere grunner til det, men det er en annen historie.

Eli Toftøy-Andersen er medforfatter av boken Praktisk brukertesting og  blogger til vanlig på brukskvalitet.no. Høsten 2011 holder hun workshop sammen med kollega Jon Gunnar Wold på  brukervennlighetskonferansen Yggdrasil 17-18 oktober og foredrag på Meetup for interaksjonsdesignere, IxdA 12. oktober.

Bloggposter fra brukskvalitet.no:
10 gode grunner til å gi avslag på publiseringsønsker 
 5 tips for brukertesting av innhold
Brukervennlighet – et folkekrav  

Andre relevante lenker:
SharePoint 2010 for Internet – Issues and solutions through a case study:
http://www.slideshare.net/jmkristiansen/ndc-presentationfinal

Innboksen som arbeidslivets kjellerbod:
http://sterkblanding.no/blog/2011/09/28/innboksen-som-arbeidslivets-kjellerbod/

En code kata er en enkel øvelse for å skjerpe programmeringsferdighetene dine. Det vil si – du trener bare problemløsning den første gangen du utfører øvelsen. Så gjentar du øvelsen, om og om igjen, til det sitter i fingerspissene. Og hver gang prøver du å gjøre det litt kjappere. Hensikten er å trene hastighet, teknikk og verktøy.

I klippet under lager jeg en variant av Minesweeper kataen i JavaScript.

(Kjør den i fullscreen for å se koden mer tydelig)

Merk: Jeg bruker testdrevet utvikling gjennom det meste av prosessen. På slutten dropper jeg TDD når jeg gjør det visuelle og selve spillmekanikken. Dette kunne også testes fra kode, men jeg droppet det for å gjøre den mer artig å se på.

Du kan se på koden i github-kontoen min. Hver commit er en separat gjennomkjøring av øvelsen fra scratch.

Jeg brukte følgende libraries og verktøy:

• Underscore.js
• jQuery
• Grid.js
• clAutotest
• TextMate

Jeg har fått dilla på dynamiske programmeringsspråk (JavaScript, Ruby, Lisp, med flere) i det siste. Et av fellestrekkene ved slike språk er at de lar deg programmere interaktivt. Vet du ikke hva interaktiv programmering er? Flott, da har du kommet til riktig artikkel!

Ideen bak er ganske enkel, men jeg tror det er enklere å vise hva det er først, istedet for å skrive masse forklarende tekst. Her er et eksempel, demonstrert med IRB (Interactive Ruby):

Hva skjer her?

Vel, jeg skriver ekstremt grunnleggende Ruby-kode. Men se hva som skjer underveis. Hver Ruby-setning jeg skriver inn blir evaluert og kjørt av systemet. Resultatet spyttes tilbake på kommandolinja. Systemet husker hva jeg gjør. Jeg definerer variabler og funksjoner. Jeg kan bruke og bygge videre på dem, og jeg får umiddelbar feedback på alt jeg gjør. Og jeg slipper å kompilere eller restarte koden min hver gang jeg prøver noe nytt.

Den vanlige prosessen vår for systemutvikling er som et stålverk. Vi lager en støpeform (skriver kode i en IDE). Så støper vi en klump stål (kompilering/restart). Dersom stålklumpen ikke har riktig form, så er det tilbake til tegnebordet for å justere støpeformen. Denne feedback-løkka er mye raskere enn før takket være raskere kompilering, bedre maskiner og enhetstesting – men vi kaster likevel bort en del tid når vi løper frem og tilbake på denne måten.

Interaktiv programmering derimot er mer som å jobbe med leire. Vi arbeider med samme stykke materiale kontinuerlig. Vi klatter på litt kode, ser hvordan det ser ut. Tar vekk ting, bytter ut, former, eksperimenterer.

Dette er ikke en erstatning for hvordan vi vanligvis arbeider, men mer et nyttig tilbehør. Du bygger ikke en produksjonsbil med leire, men det er mye lettere å lage f.eks en design-prototype med leire enn med stål. På samme måte kan interaktiv programmering være et bra hjelpemiddel og supplement for seriøs systemutvikling.

Helt konkret: hvorfor er interaktiv programmering nyttig?

• Du arbeider raskere, fordi feedback-løkka er kortere.
• Du slipper unna med mindre kode, fordi du bruker mindre tid på å bygge infrastruktur og “boilerplate”.

Mer komplisert er det ikke. Jeg mistenker imidlertid at det ene bruksområdet ovenfor ikke overbeviser helt. Jeg skal derfor vise flere eksempler, og du kan tenke over hvordan disse teknikkene passer inn i din egen verktøykasse.

Jeg bruker jevnlig interaktiv programmering til følgende:

• Utforsking og læring
• Grensesnitt mot backend-system
• Frontend-utvikling og prototyping

Utforsking og læring har vi allerede sett via IRB-klippet over. Neste eksempel er et interaktiv programmering som grensesnitt mot et kjørende system – i dette tilfellet en Ruby on Rails-applikasjon.

I filmklippet som følger lenger ned starter jeg et interaktivt konsoll på en lokal testserver. Der har jeg tilgang til det samme api’et, databasekoblinger etc som forretningslogikken i backenden av systemet mitt. Dette lar meg gå inn i en kjørende applikasjon og prøve ut nye ting, trekke ut informasjon eller gjøre små oppdateringer - mens systemet fremdeles kjører.

Man kan bruke dette konsollet til system-administrasjon i et produksjonssystem: istedet for å bygge tidkrevende web-admin-funksjonalitet i systemet ditt, så kan du la døra stå åpen for å ta de mer sjeldne oppgavene direkte i det interaktive konsollet. Bygg eventuelt web-UI for manglende ting dersom du ender med å gjøre samme oppgave om og om igjen på kommandolinja.

Dette shellet kan også brukes under utviklingsløpet for å se “hvordan ting arter seg” før man velger å forfølge noen bestemt løsningsretning med unit-tester, web-grensesnitt osv osv.

La oss flytte oss opp til frontend-utvikling. Når vi utvikler web-grensesnitt så har vi et annet interaktivt miljø vi kan bruke: Firebug-konsollet. Her er en liten demonstrasjon.

Dette var et veldig enkelt eksempel. Jeg bruker imidlertid samme teknikker når jeg jobber med mer komplekse webapplikasjoner: da bruker jeg hyppig konsollet for å prøve ut ting “live”. Metodikker som f.eks testdrevet utvikling er flott for backend-utvikling, men i visuell/frontend-utvikling er det ofte vanskelig å lage programmatiske tester siden man ikke helt vet hvordan ting kommer til å se ut og oppføre seg i nettleseren. Kanskje vet du ikke engang helt “hva du leter etter” på forhånd? Da er det fint å kunne prøve seg fram litt før man skriver for mye kode.

Nå vet jeg hva du tenker. “Men Thomas, jeg har ikke lyst å sitte og skrive kode rett inn i disse kommandolinje-greiene. Jeg liker editoren min mye bedre!” Jeg forstår den innvendingen. Du kan eventuelt skrive koden i editoren og manuelt lime den inn på kommandolinja, men det er blir fort litt knotete. Vi har mer lyst til å arbeide i en skikkelig IDE, og sende kode derfra til det interaktive miljøet. Vi skal se på et eksempel på slik arbeidsflyt i et språk som heter Clojure.

Clojure er et ungt, lovende programmeringsspråk. Det er bare noen år gammelt, men er bygget på moden teknologi. Clojure er implementert i Java, snakker pent med Java-biblioteker, og basert på LISP (en over 50 år gammel dialekt av programmeringsspråk). Det vi hittil har kalt “interaktive konsoller” blir ofte kalt Read-Eval-Print-Loops (REPL). Dette utrykket kommer opprinnelig fra LISP, som har hatt slike verktøy (og kultur for å bruke dem aktivt) i mange år.

La oss se på et eksempel i Clojure. Jeg holder meg i editoren min, og sender funksjoner og kommandoer til REPL-prosessen rett fra editoren min. I dette tilfellet bruker jeg dette til å jobbe smidig med 3d-grafikk (jeg er veldig uerfaren på dette området, og trenger derfor umiddelbar feedback på alt jeg gjør). Klippet under starter med å demonstrere helt grunnleggende ting, så tar vi steget opp til grafikk-arbeid. Mot slutten implementerer jeg rendering av et veldig enkelt  Tetris-spill.

Hva har vi sett så langt?

Interaktiv programmering gir deg rask feedback. Det lar deg jobbe hurtigere, skrive mindre kode, lære og utforske, snakke direkte med kjørende systemer, og gjøre effektiv prototyping og visuell utvikling.

Nå tenker du kanskje: “jeg arbeider med Java til daglig, hvordan kan jeg bruke disse greiene til noe nyttig?” Vel, alle disse teknikkene kan brukes sammen med Java-kode. Ruby kan kjøres på Java: JRuby er en moden platform som snakker pent sammen med Java-komponenter. JavaScript likeså: du kan enkelt kjøre JavaScript på serversiden som et interaktivt skall rundt applikasjonen din. Clojure er allerede bygd i, og beregnet for bruk sammen med, vanlig Java (3D-eksemplet ovenfor bruker allerede et Java-API for OpenGL-grafikk).

Det er derfor ikke mye som skal til for å få slike interaktive skall rundt din egen applikasjon. Kan du lukte mulighetene her?

Til slutt vil jeg gjerne at du tar en kikk på filmklippene under. De er eksempler på s.k. Livecoding, en aktivitet som ligger i skjæringspunktet mellom programmering og performance-kunst. Det som skjer i klippene under er at utvikleren koder opp improviserte algoritmer for lyd og musikk live foran publikum. Kanskje ikke nyttig umiddelbart nyttig for deg og meg, men det er et interessant eksempel på interaktiv programmering tatt til sin ytterste konsekvens.

Referanser:

A list of REPL environments

Demystifying IRB commands (interactive Ruby)

Secrets of the Rails Console Ninjas

The Firebug Console Panel

Clojure.org: ‘Getting started’

in which are found tricks of the trade concerning clojure authorship

Penumbra OpenGL framework: ‘Getting started’

Impromptu livecoding environment introduction

Andrew Sorenson livecoding videos

Språket blir dessverre behandlet som den stygge andungen av mange utviklere fordi det tradisjonelt oppleves som knotete, skjørt og lite vedlikeholdbart. Slik trenger det ikke være!

Vi i Steria har utviklet et gratis, nedlastbart kurs som oppdaterer deg på dette området. Denne workshopen introduserer ferdighetene, teknikkene og verktøyene som gjør JavaScript-utvikling langt mer overkommelig enn tidligere. Alt materiale i kurset er fritt tilgjengelig til din egen bruk.

Du kan bruke foilene, forelesningsnotatene og øvelsene som personlig studiemateriell. Du kan også holde kurset som en formell workshop sammen med kollegaer eller kunder. Workshopen tar omtrent en halv dag (3-4 timer) når det gjøres skikkelig – beregn halvannen time forelesning, minst halvannen time praktiske øvelser.

LAST NED HER

(Inneholder slides, forelesningsnotater, øvelser, løsninger, eksempler, verktøy. Utgitt under en Creative Commons Attribution 3.0 lisens. Du kan bruke, endre og dele det fritt, så lenge du krediterer opphavsmannen.)

Hvis du ikke har kapasitet til å kjøre kurset selv kan du ta kontakt med Steria; vi kan holde kurset i dine lokaler, i og rundt Oslo.

La oss avslutte med en smakebit. Filmklippet under illustrerer et av temaene som workshopen tar for seg, nemlig testdrevet utvikling i JavaScript. Enjoy!