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

“Obvious to you. Amazing to others.”

Du har garantert noe nyttig å dele. De fleste av oss er spesialiserte i ulike fagområder og ferdigheter. Ting som virker trivielle eller åpenbare for deg kan være kjempenyttig for andre. Så tenk deg om: sitter du på noe som virker “for åpenbart” til å dele med andre?

Ide-skuffen

Det er vanskelig å både finne en ide og skrive ferdig en god blogpost på en og samme kveld. Det er derfor lurt å samle og bearbeide ideer over tid.

Kjøp en notatblokk. Ta den med deg overalt. Hver gang du får en ide eller innsikt som muligens flere har nytte av, så skriver du den ned, kanskje med et par setninger. Snart har du en haug ideer og tanker som du kan skrive om.

Slik gjør jeg det: på laptopen min ligger en mappe som jeg kaller “ide-skuffen”. Til enhver tid ligger det 10-20 filer der med ulike ideer. Jeg skriver litt i dem når jeg kommer på nye poenger. Når en tekstene har nok kjøtt på beina så lager jeg bare en renskrevet blogpost av den.

Lang eller kort tekst?

En blogpost er ikke en skolestil. Det er ingen formelle krav om lengde eller struktur, så ikke stress over det: bare få ut stoffet ditt på en form som noenlunde lesbar. Finn en stil som er komfortabel for deg.

Her er to vidt forskjellige eksempler: Seth Godin og Steve Yegge. De har svært ulik form: Godin skriver noe hver eneste dag, ofte bare en paragraf eller to. Yegge derimot publiserer sjelden nye artikler, til gjengjeld skriver han da laaange tekster.

Still krav til deg selv

Det er lettere å få ting gjort når man har milepæler. Hvis man bare “venter på inspirasjonen” så koker det fort vekk i kålen. Jeg synes det er enklere å produsere ting når jeg har faste frister; jeg forsøker å ferdigstille en tekst hver kalender-måned (til enten sterkblanding.no eller min personlige blogg).

Skriveteknikk

De fleste av oss kan bli flinkere i grunnleggende skriveteknikk. Noen enkle grep gjør ikke bare blogging, men alt du skriver mer lesbart. Eksempler:

• Det er lettere å lese tekst brutt opp i paragrafer – unngå “wall of text”.
• Skriv aktivt og stramt. “Jeg grep pennen” er mer lesbart enn “pennen ble etterhvert hurtig grepet av meg”.
• Bruk enkelt, effektivt språk. “Utføre” er mer lesbart enn “operasjonalisere”.

En bok jeg liker godt er “The Elements of Style” av Strunk & White. Den er snart hundre år gammel men inneholder eviggrønne råd om skriveteknikk. Og den er selvfølgelig lettlest!

Tenk om noen er uenige med meg?

Hvis du er så heldig å få kommentarer der folk er uenige med deg så er det et tegn på at du gjør noe riktig: da skriver du iallfall engasjerende! Forsøk å få folk til å tenke “Ja!” eller “Nei!”… ikke et svakt “Tja”.

Nå, hva venter du på? Skriv!

Systemutviklere er både heldige og uheldige. Vi kan tilegne oss kunnskap og ferdigheter helt på eget initiativ, men vi tvinges også til å gjøre det for å holde oss relevante, ettersom teknologi endrer seg raskt.

Selv synes jeg at det er topp å plukke opp nye ting – her er noen metoder for å lære…

Bredde eller dybde?

Tenk på kunnskap som personøkonomi. Ikke invester alt i en aksje (“Jeg kan bare Java!”). Spre eggene dine over flere kurver. For all del: legg ned tid i mainstream-teknologi som er populær idag. C# og Java f.eks er lavrisiko med grei avkastning. Men se også på nisje-teknologi (la oss si F# eller Scala, for eksempel) Disse er mer høyrisiko fordi det absolutt ikke er sikkert de blir populære i fremtiden. Smale temaer gir til gjengjeld langt høyere avkastning hvis de slår an: du får et fortrinn fordi du var tidlig ute.

Balanse mellom generelle og spesialiserte emner. Brede, eviggrønne felt (f.eks OO-design, regular expressions, statistikk) hjelper deg i mange år, uavhengig av domener og platformer. Men ikke overse domenekunnskap og platformspesifikke verktøy (Oracle og Microsoft) som gjør deg mer ettertraktet i prosjekter her og nå.

Kultiver personlige styrker. Hvis du bare kan “litt om alt” så er det vanskelig å utmerke seg. Finn en eller to ting som er dine hovedpillarer, som du stadig forbedrer og behersker bedre enn andre. Hva gjør at du skiller deg ut? Hva er ditt “Unique Selling Point”?

Studieteknikk-kungfu

Du har et enormt arsenal av studieteknikker. Min erfaring: jeg lærer meg ting langt mer effektivt nå enn da jeg var i skoleverket eller på universitetet. Dels fordi jeg har blitt flinkere til å lære, men mest fordi vi har fått flere måter å tilegne oss kunnskap. Her er en liten godtepose av muligheter:

• Universiteter verden over legger ut åpen “courseware”: videoforelesninger, notater, pensum, oppgaver, fritt tilgjengelig på nett.
• Screencasts er en fin blanding av foredrag og praktiske demonstrasjoner. Noen av dem må du betale for. De er derfor ofte optimalisert for å levere lærdom og verdi, mer enn en umotivert foreleser på Blindern noengang blir…
• “So You’d Like To…”-guidene hos Amazon.com er i noen tilfeller knallbra utvalg av faglitteratur og fungerer bra som utgangspunkt for selvstudium.
• Online nyhetsblogger og foredrag fra konferanser gjør deg oppdatert på tilstanden i fagfeltet ditt.
• Podcasts og lydbøker gjør iPoden din til en forelesningssal – kanskje mens du tar oppvasken?
• Møt andre engasjerte i meetups, brukergrupper, code camps og online studiegrupper. Få feedback fra likesinnede, ikke gjem deg bort!
• Open source lar deg kikke bak kulissene og se hvordan andre utviklere jobber og tenker.
• Mindmapping er en sterk måte å ta gode, raske notater mens du studerer.

Og dette var bare en tilfeldig utvalg. Med andre ord: dersom du begrenser deg til å kun lese en papirbok i ny og ne så handicapper du deg selv. Du har mange muligheter!

Absorber som en svamp. Hvis jeg har en ekstrem “læredag” så hører jeg på en podcast når jeg går til stasjonen på morran, leser litt i en relatert bok mens jeg sitter på toget, plugger inn iPoden igjen når jeg bytter over til tbanen til jobben, samme opplegg på veien hjem på ettermiddagen, og setter meg ned og koder en prototyp etter at ungene har lagt seg. Teknikkene nevnt i forrige avsnitt gjør det stadig enklere å presse inn læring flere steder i hverdagen enn man kunne før.

Jevn progresjon. Store skippertak kan fungere, men det er i lengden bedre å lære litt hver dag istedet. Når man er student så fungerer sånne “overdoser” til en viss grad, men det blir vanskeligere når du har jobb og familie. Tenk bærekraftig tempo…

Bruk det du lærer

Jobb med relevante prosjekter i arbeidstida. Dette er idealsituasjonen, men lar seg ikke alltid gjøre. Prosjekter krever vanligvis at vi leverer det vi allerede behersker, ikke det vi ønsker å lære mer om. Derfor kan det bli nødvendig å…

Lage ting på fritida. Bruk det du har lært til å gjøre sideprosjekter på egenhånd. Ambisjon og omfang trenger ikke være all verden, bare du lager noe konkret og nyttig. Du kan lage et verktøy eller en tjeneste som bare du selv trenger, eller slippe det som open source eller en kommersiell tjeneste for hele verden. Poenget er at du anvender kunnskapen til noe konstruktivt. Det kan være slitsomt å bruke fritida til dette – til gjengjeld eier du selv det du lager. Og du får en “portfolio” å vise til.

Lær det bort til andre! Når du formidler til andre (f.eks via kurs, blogging, foredrag) så tvinges du selv til å få bedre grep på stoffet ditt. Du trenger ikke være guru for å lære bort ting – det holder at du har noenlunde grep om temaet og evner å formidle det godt.

Robert “Uncle Bob” Martin sa på et av foredragene sine at en profesjonell utvikler må bruke tjue timer hver uke på å forbedre seg som håndtverker. Dette er kanskje ekstremt – men hvor mye gjør du selv? Og hvordan lærer du nye ting? Del gjerne av egen erfaring i kommentarene under!

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

Jeg skal fortelle deg hvorfor du bør lære deg et s.k. scriptspråk. Scriptspråk har andre styrker enn Java og C#, og tilfører allsidighet og produktivitet til verktøyskuffen din. En kompetent håndtverker bruker mer enn hammer på jobb: skrutrekker, meisel og knipetang må også med.

Steve Yegge skrev for noen år siden en glimrende artikkel om hvordan han skiller gode utviklere fra svakere kandidater under jobbintervjuer ^[1]. Et av poengene hans er at mange utviklere har en akilles-hel: det ene språket de mestrer er ikke ideellt til alle situasjoner. De er “one trick ponies”.

Her er et intervjuspørsmål som Yegge bruker til å teste kandidater:

Last year my team had to remove all the phone numbers from 50,000
Amazon web page templates, since many of the numbers were no longer in
service, and we also wanted to route all customer contacts through a
single page.

Let’s say you’re on my team, and we have to identify the pages having
probable U.S. phone numbers in them. To simplify the problem slightly,
assume we have 50,000 HTML files in a Unix directory tree, under a
directory called “/website”. We have 2 days to get a list of file
paths to the editorial staff. You need to give me a list of the .html
files in this directory tree that appear to contain phone numbers in
the following two formats: (xxx) xxx-xxxx and xxx-xxx-xxxx.

Hvordan ville du løse dette problemet? Hint: Java og C# er ikke førstevalget til Steve, ei heller mitt. Du KAN løse dette og mange lignende problemer i Java eller C#, men et scriptspråk lar deg løse problemet raskere og mer elegant.

Så hva er scriptspråk og hvorfor er de så nyttige? Jeg definerer kort og godt disse til å være Ruby, Python, og Perl. Alle tre er modne, populære språk. Det betyr ikke så mye hvilket av dem du lærer først: alle sammen deler de fleste av følgende styrker:

• Førsteklasses støtte for å manipulere tekster og filer.
• Fungerer bra sammen med kommandolinje-verktøy og shellscripting, spesielt på unix-systemer.
• Enkle å komme igang med. Vanligvis preinstallert på Unix, Linux og OS X-systemer.
• Gode til proof of concepts og prototyper. Passer bra til å rask iterere frem og demonstrere konsepter.
• Ypperlige til å automatisere oppgaver (f.eks scripting av operativsystemer, applikasjoner, byggeprosesser).
• Er gjerne dynamisk typede språk, noe som lar deg bruke mindre tid på syntax og mer tid på selve oppgaven du skal løse. ^[2]
• Kan kjøre oppå, eller sammen med, de tyngre platformspråkene (se JRuby, IronRuby). Best of both worlds!
• Gir deg et nytt perspektiv på platformer og språk du allerede mestrer. Det er alltid nyttig å utvide horisontene sine! ^[3]

Høres dette nyttig ut? Har du lyst til å lære mer? En god måte å komme igang på kan være å lese denne boka:

eller denne:

Sett deg så ned med et konkret prosjekt. Finn f.eks en “tidstyv” i hverdagen din – en rutine som kan automatiseres. Lag et script som løser problemet ditt.

Vips: fremtidig tid spart, og du har begynt å legge et nytt, kraftig verktøy i reportoaret ditt!

Referanser:

1) Yegges artikkel om intervju-spørsmål
2) Yegge om styrkene til scriptspråk/dynamiske språk (video)
3) Robert “Uncle Bob” Martin om hvorfor du bør lære nye språk (video)

Noen av oss kjører strikt, metodisk testdrevet utvikling. Andre bruker bare automatiserte tester nå og da som sikkerhetsnett for å unngå regress-feil. Hvor ofte fyrer du selv av testene dine? Kjører du testsuiten din en gang i ny og ne, eller strikt for hver metode du implementerer?

Jeg liker å kjøre testene mine ofte mens jeg arbeider. Det jeg liker enda bedre er å la utviklingsmiljøet mitt kjøre dem for meg, automatisk. Poenget med yrket vårt er jo nettopp å automatisere og effektivisere arbeidsprosesser – dette forsøker jeg å gjøre også med mine egne rutiner og verktøy. La oss se hvordan vi kan få til dette.

Mange av oss bruker allerede Continuous Integration for å oppdage feil i den felles kodebasen. Personlig autotesting er det neste, logiske steget: enhetstestene våre burde kjøre i bakgrunnen hver gang vi endrer noe, og gi oss umiddelbar tilbakemelding når vi knekker funksjonalitet. På denne måten oppdager vi våre egne feil før resten av teamet blir påvirket av dem.

Det finnes flere verktøy som gjør dette for deg:

• Infinitest (Java)
• Autotest / ZenTest (Ruby)
• Nosyd (Python)

Det er imidlertid ikke vanskelig å lage et enkelt autotest-verktøy på egen hånd. Jeg synes at det er en god ide å bruke litt tid her og der på å forbedre sitt eget utviklingsmiljø. Vi har jo muligheten til å lage våre egne verktøy (smeden er en av få håndverkere som kan si det samme). Som utvikler bør man iallfall klare å slipe sine egne kniver, for å si det sånn. Og dette er en god anledning!

Et naivt script for autotesting implementerer du på en ettermiddag. Alt du trenger er et lite program som reagerer på endringer i prosjektfilene dine, og kjører testene etter behov.

Algoritmen er enkel: La scriptet kjøre regelmessig, f.eks hvert sekund. Kontroller “forrige endring”-klokkeslettet for alle filene i prosjektet. Dersom klokkeslettet på en eller flere filer har endret seg siden forrige kontroll, så kjør enhetstestene til prosjektet. Analyser output fra testkjøringen, og se hvorvidt noen tester feilet eller kode knakk helt (exceptions). Gi så klar tilbakemelding om testene er ok eller feilet.

Tilbakemeldingen kan være litt grafikk og lyd på desktopen (for eksempel med Growl eller Snarl), en lavalampe på pulten, blinkende LED-lamper på laptopen… vær kreativ! Bare sørg for er at du får en tydelig tilbakemelding på hvorvidt testene feiler eller ikke.

Filmklippet under viser hvordan mitt eget autotest-miljø fungerer. Koden er i dette tilfellet skrevet i et språk som heter Clojure og ser derfor kanskje litt pussig ut, men ikke heng deg opp i det: det som demonstreres er at jeg knekker og fikser tester, og får automatisk godt synlig feedback på dette underveis.

Ikke spesielt komplisert.

“Dette ser jo genialt ut! Hvorfor bruker ikke alle autotest-verktøy allerede?”

Vel, det finnes dessverre noen utfordringer.

Dersom autotesting skal fungere hensiktsmessig må testsuiten som kjøres kun bestå av raske enhetstester, ikke tunge integrasjonstester. Og enhetstestene må gå kjapt! En test-run må ta sekunder, ikke minutter, ellers mister du gevinsten ved den umiddelbare feedbacken.

Problemet med trege tester er betydelig. Det finnes workarounds: man kan analysere avhengigheter mellom tester og kode, kun kjøre de berørte testene, kjøre raske tester først, feilende tester først, nylig feilende tester først… Men mange av oss har dessverre erfart at det er vanskelig å få til et godt fungerende opplegg for dette i et vanlig moderat stort utviklingsprosjekt.

Så er ikke autotesting nyttig likevel, da? Jo! Autotesting fungerer knallbra i små prosjekter (som ikke har samlet på seg så mye kode ennå) og egenopplæring (når du lærer nye verktøy og språk og ønsker å ta små steg med kjapp feedback). Det kan kanskje også fungere i større prosjekter dersom du har muligheten til å segmentere koden og testene dine i mindre moduler på en hensiktsmessig måte.

I bunnen av denne artikkelen har jeg vedlagt et eksempel på hvordan et enkelt autotest-script kan se ut, implementert i Ruby. Scriptet er skrevet for OS X-miljø, men koden bør være relativt lesbar og enkel å porte til ditt eget favorittspråk og utviklingsmiljø.

Happy testing!

Eksempel:

# Command line command which launches all unit tests
RUN_TESTS_CMD = "mvn clean test"

# Pick up any changes in files matching this filepath
FILES_TO_MONITOR = "**/*.java"

# Determine test outcome by scraping test output for #telltale signs of failure or exceptions

def test_failed?(test_output)
  return (test_output["FAIL in"] != nil) # Any 'FAIL in' strings in test result indicates failure
end

def exception_occurred?(test_output)
  return (test_output["EXCEPTION in"] != nil)
end

# Indicate test state by turning the background color of the test terminal
# a different color - yellow red og green. Currently uses Mac AppleScripts, but could be
# an audible signal, lava lamp, or anything else instead.

def indicate_tests_running
  `osascript bin/autotest/make-term-yellow`
  puts "\n\n\n----------------------------------"
  puts "TESTRUN STARTED #{Time.now}"
  puts "----------------------------------\n\n\n"
end  

def indicate_test_success(description)
  `osascript bin/autotest/make-term-green`
  puts description
end  

def indicate_test_errors(description)
  `osascript bin/autotest/make-term-red`
  puts description
end  

$monitored_files = {} # Stores the last changed time of each file    

def files_changed? # Check if any files have been touched/saved since last check
  file_changed = false;  

  Dir[FILES_TO_MONITOR].each do |filepath|
    if(!File.new(filepath).ctime.eql?($monitored_files[filepath]))
      file_changed = true;
      $monitored_files[filepath] = File.new(filepath).ctime
    end
  end  

  return file_changed
end  

def run_test
  indicate_tests_running
  result = `#{RUN_TESTS_CMD}`  #Run the tests, pipe resulting console output back
  display_results(result)
end    

def display_results(testOutput)
  if test_failed?(testOutput)
    indicate_test_errors("SOME TEST(S) FAILED\n"+testOutput)
  elsif exception_occurred?(testOutput)
    indicate_test_errors("EXCEPTIONS OCCURRED\n"+testOutput)
  else
    indicate_test_success("ALL TESTS SUCCEED\n"+testOutput)
  end
end  

def test_loop
  while true
    if files_changed?
      run_test
    end
    sleep(1) #seconds between each poll for file changes
  end
end  

test_loop # Start testing!

Markedsføring

Begynn med grunnleggende markedsundersøkelse. Hvem ønsker du å nå, og hva trenger de å lære om temaet ditt?

Skriv  en velformulert invitasjon til kurset. Lag en skikkelig pitch – selg temaet ditt godt! Bruk grunnleggende prinsipper fra markedsføring: fortell hvorfor leseren skal bry seg (benefits) før du røper konkret pensum og detaljer for kurset (features).

Annonser kurset ditt i mange kanaler: email, sosiale medier, ansikt til ansikt. Jo fler fora jo bedre.

Sørg for at det er lett å melde seg på. Tenk på dette som å gjøre prospekter til kunder – gjør terskelen for “kjøp” så lav som mulig.

Nå strømmer forhåpentligvis påmeldingene inn. Bruk litt tid på å ta kontakt med hver deltaker. Gjør dette så tidlig som mulig. Send påmeldingsbekreftelse og ytterligere praktisk informasjon, og undersøk samtidig erfaringsnivået og forventningene til den enkelte – dette lar deg skreddersy innholdet i kurset.

Planlegging og struktur

Etter stegene ovenfor bør du ha et visst inntrykk av hvem som kommer til å dukke opp på workshopen. Generaliser denne informasjonen i personaer – skal opplegget ditt passe for både Programmerer Pia og Mellomleder Magnus?

Tenk grundig gjennom overordnet struktur og pensum. Brainstorm omfang og innhold for kurset med fleksible teknikker som whiteboard, skisser og tankekart. Feiltrinn er enkle å fikse på dette stadiet; etter at du har begynt å implementere kurset blir de langt mer tidkrevende (akkurat som systemutvikling).

Hvordan skal du lære bort? Dersom du har nok tid så bør du vurdere en kombinasjon av metoder. Litt foredrag, litt “tegn og fortell”, og rikelig med praktiske oppgaver. Hver person har sin egen måte å lære på, forsøk derfor å formidle materialet på flere måter for å treffe alle. Det gjør ikke noe at materialet derfor blir gjentatt; repetisjon hjelper folk å lære.

Presenter både grunnleggende fakta og relatert kontekst. Med andre ord, fortell både “hva er det?” og “hvorfor skal jeg bry meg?”. Mikro og makro.

Publikum kan ha varierende grad av erfaring og kunnskap om temaet du lærer bort. Forsøk i så fall å gi noe til både nybegynnerne og de erfarne elevene.

Jeg liker å starte med litt forelesning med praktiske demonstrasjoner underveis. Dette gir folk et fundament. Så bør folk få praktiske øvelser å jobbe med. Fortell, demonstrer, la folk prøve selv. (Resten av artikkelen antar at du følger dette formatet).

Foredraget

Start sterkt. Presenter en klar agenda – “hva skal vi lære idag, og hvorfor?” Bruk minimal tid på å introdusere deg selv; deltakerne er interessert i hva du ønsker å lære dem, ikke hvem du er.

Unngå foiler med masse tekst. Korte tekster er bra, enkeltord bedre, et enkelt illustrerende bilde er best. Kanskje du til og med slipper unna med å bare fortelle, dersom du gjør det tydelig nok?

Korte foiler er bedre enn tettskrevne. Så. Korte. Poenger. Som. Mulig. Hver foil fungerer da også som en veldig presis huskelapp for deg som forteller.

Foilene dine trenger ikke være kunstverk, men tenk litt grunnleggende grafisk design:

• Finn en generell stil på forhånd slik at materiellet blir så konsistent som mulig. Presenterer du samme type informasjon (eksempler, kode, lister…) gjentatte ganger? Lag da en konsekvent mal for hvordan disse foil-typene skal se ut. Kode bør f.eks alltid ha samme font og størrelse.
• Bruk stor skrifttype. Velg farger som gir god kontrast mot hverandre. Hvordan kommer materialet ditt til å se ut når det projiseres på en hvit skjerm? I dagslys? Ti meter unna?
• Bruk repetisjon. Innhold som gjentas er lettere å huske.
• Bruk kontrast. Innhold som “hopper ut av siden” er minneverdig.
• Bruk bilder av høy kvalitet. Unngå kjedelig clip-art.
• Skriv kortfattet tekst med mye whitespace rundt – la innholdet ditt “puste”.
• Kutt ut standard-malene for powerpoint. Firmalogoer og andre grafiske snurredipperier er greit på introduksjonen og avslutningen av foredraget, men på resten av foilene medfører det bare visuelt støy.

Øvelsene

Ta høyde for å bruke mye tid på å lage bra praktiske øvelser. Dette er noen poenger å tenke på:

• Øvelsene bør være enkle i starten. La eleven føle seg flink!
• Lag et bredt utvalg av oppgaver, og gjøre det mulig å løse dem i fri rekkefølge. En lang kjede av påbyggende oppgaver kan føre til at en feil i en tidlig øvelse ødelegger for eleven senere – i verste fall setter eleven seg helt fast. La eleven hoppe til en hvilken som helst annen øvelse når som helst.
• Ta høyde for at folk har forskjellig erfaringsnivå og produktivitet. En måte å gjøre dette på er å legge til en “bonusoppgave” for de flinkeste i klassen på hver øvelse.
• Ikke krev at deltakerne skal forberede seg nevneverdig før kurset. Gjør det istedet enkelt å komme igang på selve workshopen. Tenk brukeropplevelse! For eksempel: dersom oppgavene krever programmering så bør du forsøke å gi et ferdig konfigurert utviklingsmiljø til eleven.
• Anta i utgangspunktet at internett og intranett ikke er tilgjengelig, så slipper du å få ubehagelige overraskelser. Forsøk istedet å gi elevene alt de trenger for å komme igang på selve workshopen.
• Sørg for at det er enkelt å distribuere ut handouts. Kjøp en haug usb-pinner, last inn filer på dem før kurset starter.

Siste forberedelser

Når grunnleggende struktur og innhold er på plass bør du trene på stoffet og polere det ytterligere. Øving, forbedring, øving, forbedring. Iterer på innholdet flere ganger. Dette er som vanlig skriveprosess; hver gang du kommer tilbake til stoffet ditt med friske øyne så ser du ting som kan forbedres.

Forsøk å bli ferdig med det meste av forberedelser noen dager før kurset. Da gir du deg selv langt bedre margin for å avsløre og utbedre uventede mangler i opplegget ditt. Den siste kvelden før kurset passer best til rolig refleksjon og eventuell siste finpuss.

D-dagen

Møt opp tidlig. Undersøk kursrommet. Sett opp din egen pc og juster lysnivået i rommet – du har ikke lyst til å jakte etter kabler, lysbrytere og gardiner underveis i kurset.

Hils på folk etterhvert som de dukker opp. Prøv å få til litt småprat. Du ønsker å skape kontakt med deltakerne så tidlig som mulig, så tjuvstart med dette før selve kurset starter. Det er langt mindre skummelt å prate til en forsamling dersom du har noen kjente og vennlige ansikter i forsamlingen allerede.

Så kommer den utfordrende biten (iallfall for meg!): selve foredraget. Forsøk å være  avslappet og tydelig. Kontroller kroppsspråket ditt. Hold et rolig og jevnt tempo. Gjør som sangere og kamsportutøvere: bruk magen aktivt. Hent stemmen din dypt i magen, ikke øverst i halsen.

Besvar korte spørsmål underveis. Henvis lengre diskusjoner til oppsummeringen på slutten. Spesielt smale temaer kan eventuelt tas på tomannshånd etter kurset.

Engasjer publikum. Still både retoriske og reelle spørsmål til rommet. La folk svare med håndsopprekning, individuelle svar eller gruppesamtaler. Oppfordre salen til å delta aktivt!

Del inn foredraget i korte sesjoner med hyppige pauser underveis, for eksempel en halvtime av gangen med fem minutter pause mellom. Gjør disse periodene enda kortere dersom rommet er smått og trangt; lav oksygentilførsel er ikke bra.

Vår oppmerksom på publikums reaksjon underveis, og tilpass tempo og innhold hvis nødvendig. Dersom tilskuerne kjeder seg bør du skynde deg til en mer spennende del av presentasjonen. Dersom de ser ut til å “falle av lasset” bør du senke tempoet og forklare tydeligere.

Gi folk handouts etter foredraget, ikke før. Du kjemper allerede om oppmerksomhet mot mange laptoper og mobiltelefoner i rommet, ikke undergrav deg selv ytterligere ved å gi ut lesestoff i tillegg. Fokus skal være på deg og hva du sier, ikke noen utskrifter du har delt ut.

Når de praktiske øvelsene starter bør du forsøke å aktivt sirkulere i rommet. Prat med deltakerne, sjekk hvordan det går med hver person/gruppe. Tilby hjelp hvis det er nødvendig. Vær tilstede som instruktør. Det er lett å stille spørsmål til deg hvis du er i nærheten og tydelig oppmerksom. En “fjern lærer bak et stort skrivebord” virker ikke like tilgjengelig.

Til slutt: be publikum om direkte tilbakemelding. Hva synes de kan bli bedre? Basert på dette, hold en enda bedre workshop neste gang!

Referanser

Presentation Zen inneholder enkle tips rundt foredragsholding og slides-mekking.

Creating Passionate Users er en fantastisk blogg om brukervennlighet og pedagogikk. Den oppdateres ikke lenger, men arkivene er en gullgruve.

TedTalks har masse eksempler på flinke foredragsholdere. Se og lær!

Bidragsytere

Takk til Siv Fjellkårstad, Johannes Brodwall og Markus Krüger, som alle var så vennlige å dele av sine egne kurs-erfaringer!

Dette er et levende dokument. Kom gjerne med egne erfaringer i kommentarfeltet under – jeg fletter inn gode forslag i artikkelen.

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!