UK-based super hacker and long time Cucumber contributor Rob Holland announced iCuke yesterday. iCuke is a Cucumber extension that lets you write automated functional tests for iPhone apps. Here is a little teaser…

iCuke from Aslak Hellesøy on Vimeo.

For questions about iCuke, please use the iCuke mailing list.

Erfaring 1: Gratis flydata bidrar til økt datakvalitet og tjenesteorientering

Umiddelbart etter lanseringen kom kommentarene, spørsmålene og forslagene. Systemutviklere og flyspottere tok raskt tak i tjenestene og meldte tilbake om inkonsistens og mangler i datasettene. Å bli utsatt for ”amatørers” (da i ordets egentlige betydning) nysgjerrige og kritiske blikk har vært en verdifull og nyttig erfaring for Avinor. Denne “kollektive kvalitetssikringen” har bidratt til å øke kvaliteten på de aktuelle datasettene.

En annen konsekvens av frislippet har vært en mer generell dreining i tankesettet internt i Avinor. At data som tidligere kun har vært i bruk internt nå er eksponert eksternt har økt fokuset på tjenesteorientering, samt bidratt til å tydeliggjøre ansvarsforholdet mellom ulike enheter i organisasjonen. Det oppleves nå som enklere å snakke om både bruk, gjenbruk og utvikling av tjenester.



Erfaring 2: Gratis flydata bidrar til “kollektiv innovasjon”

Eksempel på iPhone-app med flydata fra Avinor

Det er ikke bare Avinor som har hatt nytte av at flydataene nå er tilgjengelig eksternt. Publikum nyter også godt av frislippet.

Kort tid etter lanseringen dukket det opp løsninger som nå hjelper Avinor med å holde det reisende publikum oppdatert på flytrafikkavviklingen. I dag benyttes Avinors API til flere ulike applikasjoner på både iPhone- og Android-plattformen, samt tjenester på en rekke større norske nettsteder.

Dette var alle tjenester som Avinor selv gjerne ønsket å utvikle, men aldri hadde anledning til å prioritere. Men som antatt i forkant; slipper vi dataene fri så vil andre lage løsningene “for oss”. Resultatet blir det samme; folk får tilgang til flytider.

(Som motvekt til iPhone-hysteriet utviklet forøvrig Avinor selv en enkel webløsning som fungerer på alle mobiltelefoner.)



Erfaring 3: Gratis flydata er positivt for omdømmet til Avinor

Lanseringen av API’et har bidratt til at Avinor ved flere anledninger har fått positiv medieomtale. De siste månedene har blant annet NRKbeta, Dagbladet.no og Teknisk Ukeblad hatt oppslag hvor Avinor trekkes fram som eksempel til etterfølgelse. Rett nok har omtalen vært relativt ”smal”, men all positiv omtale er eh… positivt (særlig når man tar i betraktning at Avinor stort sett bare er interessant for mediene når ting ikke går på skinner).

Internt har lanseringen også hatt en positiv omdømmeeffekt. Open data både føles og er moderne. Og Avinor har vært relativt tidlig ute på dette området. Per i dag har ikke altfor mange statlige virksomheter sluppet sine data til fri bruk, og innen internasjonal flytrafikk er eksemplene enda færre. Tanken på det kan gjøre en og annen ansatt i Avinor stolt. Open data bør definitivt være en målsetning, men foreløpig er det ingen selvfølge. Kudos til de som går foran.

- – - – -

Kommentar: Betydningen av erfaring 3 skal ikke overdrives. Verdien av erfaring 1 og 2 skal derimot ikke underdrives. Undertegnede er forøvrig en av flere BEKKere som jobber for Avinor.

Årsaken er at det indikerer at man har sluttet å engasjere seg. Man godtar ubrukelige regler, på tross av utvilsom støyfaktor og null verdi. Det tyder på at man ikke bryr seg om koden sin. Og kode er det mest sentrale vi produserer, kommuniserer og vedlikeholder.

Standard informasjon

Standard logginformasjon inkluderer typisk tidspunkt, alvorlighetsgrad, program- og komponentnavn i tillegg til selve meldingen. Et godt loggrammeverk tilbyr tilpasning av både innhold og format av disse parametrene.

Riktig feilhåndtering forutsetter fornuftig kategorisering og identifisering av feilhendelse. Feilkategori og unik feil-ID er en viktig del av kontekstinformasjonen.

Brukernavn

Brukernavn for den innloggede brukeren kan med fordel logges. Enkelte applikasjonsservere tilbyr denne funksjonaliteten forutsatt at du benytter de innebygde mekanismene for autentisering og logging. En teknikk man kan benytte i egen kode er å ha brukernavnet på trådkonteksten (for eksempel  en ThreadLocal variabel i Java). Når en feil oppstår henter loggmekanismen brukernavnet fra trådkonteksten og skriver det til loggen. Mange sikkerhetsrammeverk bruker også denne teknikken, det kan derfor hende at brukernavnet allerede ligger klart for bruk.

Støtte for vilkårlig kontekstinformasjon

Når en feil oppstår er det gjerne nyttig å legge til spesifikk informasjon om tilstand og kontekst. Det kan også være behov for å supplere mer informasjon oppover i kall-stacken. Rammeverket bør derfor ha støtte for å legge til vilkårlig kontekstinformasjon, for eksempel som skissert under.

public class AbstractException() {
   ...
   public void leggTilFeilinformasjon(String navn, Object info) {
      feilinformasjon.add(navn, info);
   }
}

Selvbeskrivende objekter

Når man skal logge tilstand for de ulike objektene er det en stor fordel at disse kan beskrive seg selv. Det er feil ansvarsfordeling dersom en feilhåndteringsrutine må pakke ut og formattere kontekstinformasjonen som skal logges. En slik tilnærming vil også sannsynligvis føre til inkonsistens og duplisering.

Java-mekanismen for selvbeskrivende objekter er den velkjente toString()-metoden. Ved å implementere toString() på en god måte vil tilstand kunne logges enkelt og konsistent. I tillegg er det enkelt å lage automatiserte tester for denne funksjonaliteten, og disse kan også fungere som dokumentasjon. Komponenter som Apache ToStringBuilder kan være nyttig for implementasjon av toString().

Stacktrace og uventede feil

God feilhåndtering betyr få stacktrace i loggen. Ideelt sett oppstår behovet for stacktrace kun ved programmeringsfeil; gitt at applikasjonsfeil og systemfeil er riktig håndtert og har tilstrekkelig kontekstinformasjon. Imidlertid, når en uventet feil først oppstår er stacktracen en uvurderlig del av kontekstinformasjonen. Man kan med forlel skille ut disse i en egen logg for utviklere; drift ser ofte på stacktrace som et verdiløst irritasjonsmoment.

Oppsummering

God kontekstinformasjon er en sentral mekanisme for riktig feilhåndtering. Drift og utvikling kan med stor sannsynlighet forstå og gjenskape feilsituasjonen, og dermed også rette feilen raskt. Teknikkene for kontekstinformasjon er enkle å implementere, forutsatt at feilhåndtering er en prioritert og forstått del av prosjektet.

Brukeren

Brukeren av systemet er først og fremst opptatt av at en feil har oppstått, at situasjonen er håndtert og ikke medfører senere problemer. Det er selvfølgelig irriterende og kan være problematisk når feil inntreffer, uansett er det kritisk at situasjonen ser ut til å være under kontroll. Brukeren bryr seg sjelden om årsaken til feilen, men vil gjerne kunne identifisere den spesifikke situasjonen når hun snakker med supportapparatet.

Forretningssiden

Forretningssiden (funksjonelt ansvarlige i utviklingsprosessen) forstår primært funksjonelle feil, og antar ofte at utviklere og leverandører tar seg av andre feiltyper. De ønsker generelt en applikasjon uten kritiske feil, men vil sjelden sørge for at feilhåndtering blir riktig prioritert i utviklingsprosessen.

Kunde/Bestiller

Den som sitter på budsjettet og bestiller applikasjonen har forventninger om en fungerende applikasjon, men har vent seg til at ingen applikasjoner er feilfrie. De er vanligvis ikke tilstrekkelig involvert i prosjektet til å påvirke og vektlegge feilhåndtering. Noen stiller imidlertid med testledere som kan være erfarne nok til å ivareta dette ansvaret og sørge for at unntaks- og feilsituasjoner blir testet.

Drift

Drift vil vite hva de skal gjøre når feil oppstår. På kort sikt er drift kun interessert i å gjøre grep slik at systemet kjører videre og ikke har havnet i en ugyldig tilstand. Selv om årsaken til feilen kan være interessant vil driftpersoner sjelden ha behov for detaljerte beskrivelser. Imidlertid vil de gjerne ha en oversikt over potensielle og kjente feilsituasjoner, kunne gjenkjenne feilkategoriene og kanskje bygge opp en erfaringsbase over tid.

Utviklere

Utviklere vil vite alt:

• Hva var årsaken til feilen?
• På hvilken server skjedde den?
• Når oppsto situasjonen?
• Hvilken tilstand hadde brukeren og applikasjonen?
• Hva var kontekst i feilsituasjonen?
• Kan den gjenskapes?

Ettersom utviklere ofte står for feilhåndteringen vil utviklerbehovene prege implementasjonen. Dette resulterer gjerne i detaljerte feilmeldinger i alle sammenhenger; i brukergrensesnittet, loggfiler og konsoller.

Tilpasning til brukernes behov

For bedre feilhåndtering må man i større grad skille mellom ulike brukergrupper og deres behov. Her er noen mulige tilnærminger:

• Utviklingsprosjektet må ta hovedansvaret for feilhåndteringen. All erfaring tilsier at man ikke kan forvente at forretningssiden eller bestiller vil sørge for at behovene beskrives og prioriteres. Dersom kunden ikke har en erfaren testleder bør prosjektene selv bekle denne rollen.
• Unngå detaljerte feilbeskrivelser i brukergrensesnittet, men oppgi gjerne en unik feil-ID slik at det er mulig å finne tilbake til den spesifikke feilen.
• Involver drift i hele utviklingsprosjektet slik at de kan bidra til kravstilling og kommunisere sine behov på lik linje med funksjonelle krav.
• Sørg for konsistent feilkategorisering som drift kan bruke for å kjenne igjen feil.
• Bruk gjerne forskjellige logger for drift og feilretting. Drift har i utgangspunktet ikke behov for de detaljerte feilbeskrivelsene som man har i forvaltning.
• Sørg for å legge til kontekstinformasjon i feilsituasjoner.

Når man feilsøker kan man skille mellom to ulike behov:

• Feilkategori beskriver hvilken feil som har oppstått. Den kategoriserer hendelser av samme type, og brukes for å forstå hva som har skjedd.
• Identifisering av feilhendelsen forteller hva som har skjedd til en bestemt tid i en spesifikk sammenheng. Typisk er dette nyttig for å finne ut hva som har skjedd når man feilsøker en bestemt feilsituasjon meldt av en bruker.

Feilkategorisering

Feilkategorisering har flere alternative tilnærminger:

• Hver feilkategori representeres med en egen Exception. Java SE APIet er et eksempel på denne tilnærmingen. Dette resulterer typisk i mange Exception-klasser  definert på ulike steder i pakkestrukturen. Tilnærmingen kan derfor kalles distribuert.
• Et fåtall sentrale Exception-klasser definerer feiltypene (gjerne Applikasjonsfeil, Systemfeil og Programmeringsfeil). For hver feiltype defineres en ID som feiltypen bærer med seg (typisk en Enum spesifisert i constructor). Denne tilnærmingen kan ses på som sentralisert.
• Kombinasjoner av disse, for eksempel et fåtall sentrale Exception-klasser med distribuerte subklasser.

Sentralisert feilhierarki

Uavhengig av tilnærming er hensikten å gjenkjenne feilen og forstå hvorfor den oppstår. En driftsperson vil kanskje lage en erfaringsbase for kjente feilkategorier. En utvikler som skal feilrette har også god nytte av god feilkategorisering for å finne årsaken.

Min erfaring er at applikasjoner lykkes best med en sentralisert tilnærming, der man definerer feilkategoriene som en felles Enum. Rammeverk (f.eks. Java SE API og Spring Framework) velger gjerne en distribuert tilnærming; ettersom dette ikke er applikasjoner har man ikke det samme behovet for sentral oversikt over feilkategoriene.

Enum Kategori { INGEN_PENGER, FEIL_ROLLE, UTESTENGT };
...
 
public class AbstractException() {
   public AbstractException(Kategori kategori, ...) {
      ...
   }
}

Kategorisereing av feil ved hjelp av Enum

Identifisering av feilhendelse

For å finne ut av en spesifikk feil ønsker man å identifisere den unike hendelsen som forårsaket feilen. Typisk er dette en situasjon der en bruker melder en feil eller når man feilsøker en hendelse som andre har rapportert tidligere. Å kunne identifisere denne ene feilen i en stor loggfil er gull verdt. Dette krever at hver enkelt feil blir logget med en unik ID.

En teknikk som fungerer bra nok i de fleste sammenhenger er å bruke tidspunktet feilen oppstår (i millisekunder) som ID. Denne IDen vises i feilsammenheng og skrives samtidig til feilloggen. Sannsynligheten for at to eller flere feil oppstår i samme millisekund er tilstede, men denne teknikken vil uansett begrense utvalget til et minimum. Funksjonaliteten for å lagre IDen implementeres i Exception-superklassen.

public class AbstractException() {
   private final long uid;
   public AbstractException(...) {
      uid = System.currentTimeMillis(); // skrives til loggen
   }
}

Eksempel på identifisering av Exception-instans med timestamp.

Oppsummering

God feilhåndtering forutsetter riktig kategorisering av feil i tillegg til støtte for å identifisere hver enkelt feilhendelse. Som alltid krever dette at man har et bevisst og målrettet forhold til feilhåndtering gjennom hele prosjektløpet. Det er fullt mulig å unngå at feilkategorisering og idendifisering av feilhendelse blir klattet på mot slutten av et prosjekt; å involvere driftpersoner som kravstillere på lik linje med annen funksjonalitet er en god start. God kontekstinformasjon i en feilsituasjon er også viktig, dette blir et eget tema i denne serien.

• Applikasjonsfeil
• Systemfeil
• Programmeringsfeil

Applikasjonsfeil skyldes at funksjonelle forutsetninger ikke er tilfredsstilt. I praksis er dette gjerne ugyldig eller feilformatert input som for kort fødselsnummer, e-postadresse uten @, dobbeltføring av betaling eller en kunde som har utilstrekkelig bonusnivå for å utføre en handling. Applikasjonsfeil kan sies å være forventet og skal håndteres på lik linje med andre krav. Det kan være krevende å forutse alle slike feilsituasjoner. Erfaringsmessig har forretningsfolk god oversikt over de vanligste funksjonelle problemene, mens teknikere er flinke til å tenke på grenseverdier og inkonsistens. En iterativ tilnærming med teknikker som test-drevet utvikling, brukerhistorier og BDD vil avsløre de fleste applikasjonsfeilene. I utgangspunktet skal det ikke være nødvendig å feilrette og rulle ut en ny versjon av applikasjonen for denne typen feil. For å håndtere applikasjonsfeilene som allikevel slipper ut i produksjon er det viktig med hyppig utrulling slik at man kan fange opp disse etterhvert som man får praktisk erfaring med systemet.

Systemfeil skyldes feil i applikasjonens omgivelser eller infrastruktur. Typisk er dette en disk som går full, et nettverk som blir utilgjengelig eller en server blir overbelastet. Slike feil er også til en viss grad forventet; de opptrer sjelden, kan være vanskelig å forutse, men i praksis er det gjerne rimelig enkelt å teste slike feilsituasjoner. Ved systemfeil kan det gi mening å kjøre fail-over om mulig, alternativt vente en stund for deretter å prøve operasjonen på nytt; denne type feilhåndtering tilbys gjerne av meldingssystemer. Feilretting og ny utrulling skal ikke være nødvendig for denne feiltypen.

Programmeringsfeil skyldes at utviklere ikke har gjort jobben sin. De oppstår når applikasjonen ikke klarer å håndtere uventede hendelser på på robust vis. Typiske eksempler på dette (i en Java-applikasjon) er når systemet spyr ut feil av typen NullPointerException, NoSuchElementException og IndexOutOfBoundsException. Godt håndtverk med teknikker som TDD og automatisert testing, parprogrammering og kodegjennomgang er effektive tilnærminger for å minimere denne typen feil. Når en programmeringsfeil oppstår krever det en feilretting og påfølgende utrulling av ny versjon.

Tabellen under gir en oversikt over feiltypene og om de bør fanges og håndteres i applikasjonen, om det er mulig å vente litt og prøve operasjonen på nytt samt om den krever feilretting og utrulling av ny versjon:

Dårlig feilhåndtering er dessverre alt for utbredt i vår industri. Antall stacktrace i loggen er en indikator på hvilken kvalitet applikasjonen har; applikasjonsfeil og systemfeil skal være håndtert mens programmeringsfeil skal være luket ut i utviklingsprosessen. Et bevisst forhold til feiltyper og hvordan de bør håndteres er et godt utgangspunkt for å lykkes på dette området. Riktig feilhåndtering krever imidlertid målrettet innsats gjennom hele utviklingsløpet.

Hvis man tar innover seg gjeldsbegrepet så er det i praksis ikke gjelden, men rentene som kjennes på kroppen. Vi mener at det er mer hensiktsmessig å måle tekniske renter enn teknisk gjeld. Rentene kan man enkelt finne ved å se på differansen mellom hvor lang tid det tar å implementere en oppgave i et nyoppstartet utviklingsprosjekt i forhold til i forvaltning. Hvis man bruker 1 time på å lage en avkryssningsboks i nyutvikling og 8 timer i forvaltning, kan man regne med at 7 av disse timene er renter. Hastigheten man en gang hadde er nå redusert, differansen velger vi å se på som tekniske renter. Dette er tid som er lite nyttig og oppleves som frustrerende, tid som vi gjerne ønsker å bruke til noe annet.

I BEKK forvaltning har vi mange prosjekter med en hel del nedskrevet og noe glemt gjeld. Vi har undersøkt om vi kan måle de tekniske rentene på denne gjelden og om dette kan gi oss et bedre bilde av hvilke utfordringer vi står ovenfor. Målet er å kunne gjøre forvaltning av applikasjoner på en bedre måte.

Ved å notere når man betaler tekniske renter fant vi raskt ut hvilken størrelseorden gjelden var på. Samtidig ser vi i hvilken del av applikasjonen gjelden befinner seg. Delen med gjeld er den delen av systemet man jobber med når rentene betales. Grafen under viser hvordan vi ser for oss en slik rentebetaling gjennom utviklingsløpet. Hastigheten eller “Valuta for pengene” på y-aksen og tid langs x-aksen.

De faktorene vi har tatt for oss vil hver for seg senke utviklingshastigheten. Hver av faktorene peker på et området hvor vi betaler renter og derfor har teknisk gjeld. Det finnes mange flere punkter og de varierer selvfølgelig fra prosjekt til prosjekt. Dette er vår liste, du kan sikkert finne flere punkter vi hadde satt pris på om du legger de til i kommentarfeltet.

Figuren over viser at hvis man for eksempel mister fokus på å skape verdi så vil hastigheten synke over tid. Hvis man i tillegg mister overføring av kompetanse vil utviklingshastigheten reduseres ytligere på grunn av manglende kompetanse hos de som skal gjøre jobben framover. Konsekvensen av de ulike punktene akkumulerer slik at de totalt bidrar til en reduksjon av utviklingshastigheten.

Verdifokus
Prosjekter som har gått lenge har ofte en tendens til å bli preget av at prosjektet i bunn og grunn består i å rette feil. Det har tapt verdifokus i og med at man jobber med ting som ikke nødvendigvis gir mest verdi for pengene. I disse situasjonene har man ofte mistet overblikket og retningen for hvorfor prosjektet er i drift. Samtidig som koden man skriver blir vanskelig å vedlikeholde når de store linjene ikke tydelig kommer fram.

Kompetanse
Ofte ser vi prosjekter som sprinter mot lansering og i det prosjektet er ferdig går hele teamet over på nye prosjekter. Med de forsvinner også viktig kunnskap. Vi ser at ved å overlappe forvaltningsteamet med utviklingsteamet (dette kan gjøres på mange måter) slipper vi å gjenoppdage rutiner og konvensjoner. Tid man kan bruke på viktigere ting.

Automatiserte tester
Prosjekter av en viss alder har ikke automatiserte tester, eller tester i det hele tatt. Renter blir her betalt ved å opprette tester og regresjonstester for de delene av systemet hvor man skal gjøre endringer. Det å få tilbakebetalt disse rentene kan ta mye tid, men vi obsererer gang på gang at det er helt essensielt for at utviklinghastigheten skal øke.

Byggerutiner
Hvis noe gjør vondt, gjør det ofte. Hvis du gjør noe ofte, automatiser det. Det sier seg selv at slike oppgaver er repetitive, og hvis du gjør dem ofte tar de mye tid. Som igjen gjør at du bruker mye tid på å gjøre disse oppgavene.

Historie
Vi har i noen prosjekter brukt mye tid på å finne bakgrunnen for en designavgjørelse. I andre prosjekter har dette vært dokumentert ved god og uttrykksfull kode eller i form av en god og forståelig commit melding. Dette er steder hvor informasjonen er knyttet til kontekst (revisjon eller integrasjonspunkter) og hvis integrasjonspunktet endrer seg vil man med større sannsynlighet slette koden, i motsetning til dokumentet som omhandler det.

Hvert av punktene beskriver hvordan vi identifiserer at vi betaler renter og hvordan vi løste våre problemer. Det vi ønsker å få fram er ikke nødvendigvis størrelsen på den tekniske gjelden men hvordan man identifiserer den ved å se på betaling av renter. Ved å identifisere det vil man også være i en bedre posisjon for å ta problemet ved roten.

Konsekvensene ved å ta opp teknisk gjeld er ikke nødvendigvis gjelden i seg selv, men rentene du betaler på den. Dette viser seg i den ekstra tiden du bruker på oppgaver som gikk raskere før. Gjelden må håndteres for at utviklingshastigheten ikke skal bremse opp. Det koster dine kunder mye, og gir deg kjedelige oppgaver.