Category Archives: Norsk

Articles in Norwegian

Husk å melde deg på til Smidig 2010

Smidig 2010: Norges største smidige konferanse

Har du fått med deg at Smidig 2010 arrangeres 16.-17. November på Radisson BLU, Holberg plass i Oslo? Konferansen har åpnet for foredrag. Early bird prisen på billetter varer KUN TIL TORSDAG, så det gjelder å bestemme seg fort!

Opplev vårt unike format, med over 70 lyntaler og 100 diskusjonsgrupper! Smidigkonferansen er den årlige nasjonale hendelsen som samler mennesker fra alle typer roller i IT-bransjen; prosjektledere, produkteiere, utviklere, bedriftsledere og testere og flere.

Posted in Extreme Programming, Non-technical, Norsk | Leave a comment

Å trene på Java EE

For å bli bedre må man trene. For å bli bedre med avanserte ting, må man forstå de grunnleggende tingene bra. For å vite hvorfor man bruker avanserte verktøy, må man prøve å jobbe uten dem. Derfor har jeg de siste ukene trent mange ganger på å lage en veldig enkel webapplikasjon i Java. For hele applikasjonen har jeg startet med å skrive testene før koden som implementerer funksjonaliteten.

Dersom du vil prøve deg på samme øvelse, inneholder denne artikkelen litt informasjon for å komme i gang. Start med koden under og følg feilmeldingene. Send en kommentar dersom du ikke kommer videre fra en feilmelding, så får vi en FAQ.

Oppgaven

Løs et så enkelt som mulig problem som involverer websider og database med så enkel teknologi om mulig.

Oppgaven jeg har laget går ut på å opprette personer med fullt navn og søke etter personer basert på navnet deres. For å gjøre oppgaven så lite som mulig har jeg valgt å la personer kun ha ett informasjonsfelt: Fullt navn. Denne oppgaven tar cirka 2-3 timer uten øvelse og du kan få den ned i 60-90 minutter med trening.

Du kan naturligvis velge en annen oppgave, men uansett hva du velger: Det er mer lærerikt å gjenta den samme oppgaven flere ganger enn å utføre en avansert oppgave.

Når jeg utfører oppgaven er det viktigste jeg lærer meg å forstå feilmeldingene som guider meg gjennom utviklingen. Dersom du trenger hjelp til å komme til de første feilmeldingene kan du se resten av artikkelen.

Steg for steg: Startpunktet

Selv om jeg valgte veldig enkel teknologi for implementasjonen, har jeg valgt et større sett med biblioteker for å skrive testene. Jeg bruker følgende når jeg skriver testene:

  • JUnit 4.6
  • Jetty 6.1.22
  • HSqlDb 1.8.0.10
  • WebDriver-HtmlUnit 0.6.1039
  • Mockito 1.8.0
  • FEST-assert 1.2 (ikke påkrevd, men gjør testene søtere)

Den eneste teknologien jeg har valgt for implementasjonen er Servlet-API 2.5 og Hibernate-Annotations 3.4.0.GA.

For at du skal slippe å plundre så mye med avhengigheter før du kommer i gang har jeg laget en pom.xml-fil som du kan ta utgangspunkt i.

Web-tester

For å starte utviklingen, er det lurt med en test som starter på utsiden av applikasjonen. Noe slikt:

  1. Start opp miljøet
  2. Legg inn en person
  3. Søk etter personen

Slik kommer du i gang med en test som går mot en web applikasjon:

Dette oppsettet forventer å finne web.xml-fila på src/main/webapp/WEB-INF/web.xml.

Funksjonell test

En funksjonell test definerer kravene i applikasjonen. Det er lurt å gjøre funksjonelle tester så raske som overhode mulig, samtidig som de går gjennom alle kravene. En funksjonell test trenger ikke være en ende-til-ende test, slik som eksempelet over. Dette er viktig, fordi ende-til-ende tester er ofte veldig trege. Her er noen eksempler på funksjonelle tester:

  • Vis en siden for å opprette nye personer
  • Opprett en ny person
  • Verifiser at personens navn er oppgitt og ikke inneholder ulovlige tegn
  • Vis en side for å søke etter personer
  • Vis alle personer dersom søkestreng ikke er angitt
  • Søk etter angitt søkestreng

En funksjonell test kan se slik ut:

Data-aksess-test

Hibernate forenkler databasebruken mye. Men Hibernate er selv komplekst og når man bruker det på mer avanserte måter fortjener det egne tester. En typisk test med Hibernate kan være:

  1. Legg i tre personer i database
  2. Søk etter en del av navnet på en av dem
  3. Sjekk at du får tilbake akkurat den du forventet

Når jeg starter med Hibernate, lager jeg en test som dette, og følger feilmeldingene. Pass på å både følge feilmeldinger i loggen og stack tracer.

Følg feilmeldingene herfra.

Integrasjon

En veldig vanlig måte for web serveren å overlevere spesielt ting som DataSources til applikasjonen er via JNDI. I Jetty kan du gjøre dette i Web-testen på følgende måte:

Konklusjon

Å gjøre en liten øvelse som dette er en god måte å bli bevisst hvilke vaner du har og hvor lang tid det egentlig tar for deg å gjøre oppgavene dine. Du vil oppleve at det å skrive tester før koden føles som om det går saktere enn du tror du er vant til.

Men dersom du er som meg, vil du også oppleve noe annet: Når du tester ut applikasjonen første gang (du kan gjøre dette med Jetty, naturligvis) så er sjansene gode for at den vil være nokså feilfri og at debugging i stor grad er overflødig. Jeg vet ikke med deg, men debugging er en aktivitet jeg gjerne blir kvitt.

Posted in Extreme Programming, Java, Norsk, Software Development | 18 Comments

Tips for databasemigreringer

En kollega spurte i dag om mine topp tips når det gjelder databaserefactorings. Her var mitt svar:

  1. Ha en organisert struktur med at man gjennomfører navngitte migreringer (a la Ruby-on-Rails sine migrations eller dbdeploy). Typisk er det vanlig og velfungerende å navngi scripts med løpenummer (001, 002, …) eller timestamp (20091124071300, …) og ha en tabell i databasen som holder styr på hva som har blitt kjørt
  2. Bruk views og materialiserte views for å støtte tilbakekompabilitet (NB: Oracle er veldig sterk på dette, andre databaser kan slite)
  3. Om mulig, gjør hver migrering bakoverkompatibel på en versjon av programvaren. Dette er lettere å få til jo hyppigere du releaser programvaren
  4. Skill endringer i skjema (for eksempel: legg på en kolonne) fra migrering av data (for eksempel: populere kolonnen). Feilene vil typisk ligge i #2 av disse, og den er lett å gjøre transaksjonell, mens skjemaendringer ikke er transaksjonelle i de fleste baser.

Har jeg dekket det viktigste da?

Posted in Norsk, Software Development | 17 Comments

Lær Scrum på 3 minutter

This Norwegian language article introduces a short two-page guide I’ve written to explain Scrum to people who’ve only just heard of it.

I samarbeid med våre dyktige redaksjonelle medarbeidere på Steria, har jeg forfattet en “3 minutters guide” til Scrum. Denne tar for seg spørsmålene som “hva er egentlig Scrum”.

Hva er egentlig Scrum
Dette er Scrum

3-minutterguidene kan lastes ned fra Sterias hjemmesider.

Jeg planlegger å følge opp denne guiden med en guide som beskriver hva som skal til for å faktisk lykkes med Scrum. Har du noen ideer?

Posted in Extreme Programming, Non-technical, Norsk, Software Development | Leave a comment

En lynrask innføring i Scrum

This Norwegian language post talks a little about a quick intro to Scrum that I wrote for my employer

Jeg har forfattet en “3-minutters guide” til Scrum. Dette er en to siders lettlest artikkel som publiserer via min arbeidsgiver Steria. Denne har som mål å være tilgjengelig både for tekniske og ikke-tekniske prosjektdeltagere som gjerne vil forstå litt mer om hva Scrum dreier seg om.

Du finner artikkelen på Sterias arkiv over 3-minuttersguider. Du kan ta kontakt dersom du ønsker et eller flere eksemplarer av guiden trykket på solid papir.

Jeg regner med å lage flere iterasjoner av denne guiden, så tips om forbedringer mottas med takk.

Posted in Non-technical, Norsk, Software Development | 8 Comments

Den Smidige myte?

This is a Norwegian language copy of an article I published with Niklas Bjørnerstedt in the Norwegian computing magazine ComputerWorld

Studier som utgir seg for å være vitenskapelig utført viser seg stadig å ikke tåle nærmere granskning. Kommersielle tenkesmier tar mange snarveier i kampen om å få frem oppsiktsvekkende resultater. Forskeren Magne Jørgensen har gjennom årene bidratt til å “avsløre” flere tvilsomme studier og dermed bidratt til å heve den vitenskapelige standarden innenfor systemutvikling. Vi synes dette er en hederverdig innsats som vi har lært mye av. Vi synes dog at Magne har blitt overivrig i det siste. I både artikler og foredrag virker han å fremfekte et syn som stiller spørsmålstegn ved all erfaring som ikke er vitenskapelig bevist. Det siste eksemplet på dette synet sto å lese i CW den 24. mars. Når artikkelen bruker denne skepsisen til å koble smidig utvikling med ord som “mote” og “tro” så føler vi at forskeren er i ferd med å kaste ut barnet med badevannet.
(more…)

Posted in Extreme Programming, Norsk, Software Development | 3 Comments

Alt kan refaktoreres

This blogpost is a Norwegian language tribute to one of my home city’s great poets

Med takk til Joachim Nielsen

Ta en titt inn på skjermen din æ’kke testen grønn
Det var mye værre her om da’n da var alle tester røde
Skulle vært her i forrige uke, da hadde byggserver’n stopp
Alt jeg tenker på er test og kode og bygg og mat hver bidige dag

Alt kan refaktoreres, alt kan leveres
Alt kan refaktoreres, og ingen ting blir bedre

(more…)

Posted in Extreme Programming, Norsk, Software Development | 5 Comments

Vær-varsom plakaten for arkitekten

På dagens møte i IASA Oslo fremsatte jeg påstanden at vi trenger en “vær-varsom plakat” for arkitekten. Spesielt fokuserte jeg på virksomhetsarkitektens rolle og risiko.

I diskusjonen etterpå kom vi inn på mange av aspektene og det var mange veldig gode forslag der jeg ikke fikk notert meg alt, så jeg har utelatt mange ting som kunne vært sagt.

Her er mitt førsteutkast til “vær-varsom plakaten”:

  • Hold tilbake til innflytelse: Når du foreslår en løsning, kan løsningen bli valgt ukritisk. Når du tar ansvar for en løsning, umyndiggjør du de som skal utføre jobben og gjør dem i dårligere stand til å ta ansvar i fremtiden.
  • Vær forsiktig med å foreslå løsninger: Løsningen du foreslår har høyere kostnader enn du forventer. Løsningen du foreslår løser problemet dårligere enn du forventer. Problemet du løser er mindre alvorlig enn du forventer.
  • Byråkrati koster: Alle tid brukt i møter er tid som ikke brukes til fremdrift. All unødvendig informasjon (for eksempel standarder) som blir gitt fjerner oppmerksomheten fra en bit viktigere informasjon.

I stedet kan en arkitekt fokusere på å være en kulturkatalysator:

  • Skap fora for andre: Du har en unik mulighet til å støtte læring og erfaringsutveksling mellom de som utfører jobben.
  • Fremhev andre: Dersom du kjenner andres sterke sider og forbedringsønsker, har du mulighet til å bidra til andres personlige vekst.
  • Vær et talerør: De som gjør oppgavene har ofte vanskelig for å få gehør for sine problemer og behov. Formidle disse problemene til ledelsen og hjelp sett fokus på daglige forbedringsmuligheter.
Posted in Norsk, Software Development | 15 Comments

Lyntalemanifestet

I’ve been part of the group organizing the Norwegian language, lightning talks based conference Smidig the last two years. This Norwegian language article describes the essential guidelines to giving a short presentation.

En god lyntale kan ha enda større påvirkning enn et godt foredrag, fordi lettere kan nå flere mennesker. Men det krever innsats. En god lyntale er:

  • Fokusert: Du skal ha ett poeng, én påstand eller ett spørsmål som foredraget bygger rundt. En god lyntale er ikke kortversjonen av et timesforedrag, eller abstraksjon over erfaringer. Snakk om konkrete erfaringer. Finn det aller viktigste poenget og snakk om det.
  • Forberedt: En lyntale krever forberedelser, akkurat som et annet foredrag. Men siden det er kort har du anledning til å trene på det flere ganger. Vis ditt publikum respekt. Hold talen for en vegg tre ganger før du holder den for et menneske. Det tar bare 30 minutter.
  • Pirrende: Når tiden din er brukt opp skal du ikke ha sagt alt du kunne ha sagt, og ditt publikum skal ikke ha hørt alt de kunne ha hørt. Både du og publikum bør ha appetitt på mer informasjon.

Kan du skape mening på ti minutter? Klart du kan.

Kommentarer, eksempler på gode lyntaler og forslag til revidering av “manifestet” mottas med takk!

Posted in Communities, Norsk | 10 Comments

Er smidige målprisprosjekter mulig?

The Norwegian computing association has released guidelines for contracts regarding agile projects. Wednesday, November 26th I will be part of a panel debating this work and the combination of agile and contracts. This Norwegian language blog post contains my introductory remarks for the debate.

Kom på debatten på Oslo Lean Meetup på onsdag og delta på debatten!

Jeg er ikke en prosjektleder, en advokat eller en politikker, så jeg kan ikke si så mye om hva som må være med i en slik kontrakt. Jeg er bare en programmerer. Jeg er en programmerer som ønsker å jobbe på gode prosjekter. Jeg håper at det er mulig for meg å jobbe på gode prosjekter som også advokatene og politikerne vil være fornøyde med.

Hva er et godt prosjekt? Den enkle definisjonen er at et godt prosjekt er et prosjekt som både leverandøren og kunden, både utviklerne og brukerne er fornøyde med. For meg som programmerer er dette viktig. Og jeg tror det er viktig for mange andre programmerer. Hva er det som gjør at enkelte mennesker synes programmering er spennende? Jeg tror svaret er enkelt: Programmerer er mennesker som brenner for å skape ting som noen har bruk for.

Jeg ønsker å skape verdi, og for meg er smidige metoder en god rettesnor. Jeg tror ikke smidige metoder er et magisk ord man kan bruke for å få til vellykkede prosjekter, men jeg tror at verdiene smidige metoder beskriver forbedrer sjansene mine for å delta på gode prosjekter. Men bare dersom man forstår verdiene og ikke bare utfører tomme ritualer som man kaller “smidig”.

Jeg har jobbet noen år som programmerer. Og jeg har deltatt både på prosjekter jeg var fornøyd med og på prosjekter som jeg ikke var fornøyd med. Den triste sannheten er at de fleste prosjektene jeg har sett eller deltatt på var ikke gode prosjekter.

Derfor var det veldig spennende for meg når jeg først fikk høre om veillederen. Spørsmålet jeg håper veilederen kan svare på: Er det mulig å forbedre sjansen for at leveranseprosjekter blir gode leveranseprosjekter? Kan veilederen forbedre sjansen for at prosjektene våre blir gode prosjekter?

Jeg har lest gjennom det som har blitt skrevet med en blanding av håp og skrekk. Mitt svar er “jeg vet ikke”.

Men jeg er skeptisk. Det virker som om smidige metoder, som mye annet, er i ferd meg å bli et offer for sin egen suksess. Kan vi risikere å falle i fella at vi tror at fordi vi bruker ord som Product Owner og ScrumMaster og Sprint og Product Backlog så vil alt bli bedre av seg selv?

Det er lett å si “smidig”, men det er ikke alltid lett å gjøre smidig. Så for å forstå hva smidige metoder dreier seg om, gikk jeg tilbake til kilden.

Jeg bladde opp på http://agilemanifesto.org. De smidige verdiene er kjent for de fleste nå. De står på forsiden. Men det ser ut som om mange overser den første linken herfra. Den går til de tolv smidige prinsippene. Jeg har valgt ut tre for dere:

“Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”

“Simplicity–the art of maximizing the amount of work not done–is essential.”

“Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.”

Det jeg har fått ut av smidighet, er erkjennelsen om at vi ikke kan anta perfekt informasjon. Vi er nødt til å få feedback på det vi tror og det vi gjør, og vi er nødt til å endre planene basert på denne feedbacken. Denne grunnleggende verdien ligger bak ønsket om hyppige leveranser og mye annet.

Så jeg står igjen med et siste spørsmål: Er det mulig å lage en leveransekontrakt som verdsetter denne dype verdien om feedback? Det håper jeg å få svar på i denne debatten.

Posted in Communities, Extreme Programming, Norsk | 4 Comments