- Jeg har pint meg selv med utfordringer

Ukas Koder Mikkel Dan-Rognlie i Bekk er over snittet opptatt av Java og backend-utvikling.

Mikkel Dan-Rognlie forteller om starten med storebrorens Amiga 500, helt til backend-utvikler i Bekk. 📸: Privat
Mikkel Dan-Rognlie forteller om starten med storebrorens Amiga 500, helt til backend-utvikler i Bekk. 📸: Privat Vis mer

Hvordan begynte du med koding? 👶

Jeg startet egentlig forholdsvis sent i forhold til noen andre jeg har lest om her på Ukas Koder. Jeg hadde aldri riktig blitt introdusert eller hatt interessen for koding utover å ha sett over skulderen på min storebror som er 6 år eldre. Han var den heldige som hadde en Commodore 64 og lekte seg med Basic og senere en Amiga 500.

Første gangen jeg selv begynte med koding var vel på videregående, hvor vi hadde et multimedia-fag og jeg lagde en egen hjemmeside. Jeg tror det var i Frontpage, så man kan jo diskutere hvor mye koding det var! 🙈

Etter tre år på videregående startet jeg på det vi i Danmark kaller en "2-årig kortere videregående utdanning". Jeg tok "Multimediedesigner" som lå i krysningen mellom design og utvikling. Det var en god blanding av f.eks. grafisk design, UX, spill- og webutvikling.

Jeg økte webutviklingen et nivå og lagde nå websites i Macromedia Dreamweaver og brukte HTML-tables og små transparente GIF'er for design/layot og runde hjørner. 🙈 Etter hvert begynte jeg med Macromedia Flash og kodet interaktive websites og små spill med ActionScript og snasne animasjoner.

Etter studiet til Multimediedesigner jobbet jeg en stund med å lage e-læringsprodukter i Flash og hadde et eget lite firma på siden hvor jeg designet grafiske profiler og (statiske) websites for kunder med faktisk håndskrevet HTML og CSS. Kundene ble fort krevende og ville gjerne kunne legge innhold og nyheter inn dynamisk. Dette var vel i ca. 2001, så det fantes ikke så mye ut av boksen for dette.

Jeg begynte derfor å lære meg PHP og MySQL og lagde et mini-CMS til de få kundene mine som ville ha sånn dynamisk innhold. Etter hvert skjønte jeg at programmering var tingen, og jeg hadde lyst på å lære dette skikkelig. Jeg tok derfor en Bachelor i "Medialogy" fra Aalborg Universitet og senere en Master of Science på T-Universitetet i København, med spesiale i softwareutvikling og fag som man kjenner det fra Dataingeniør her i Norge.

Etter endt utdanning i 2007 startet jeg som konsulent i et firma i Danmark som spesialiserte seg på kurser og utvikling på Java/J2EE-plattformen, og mitt første prosjekt var et stort SOA-prosjekt i Danmark kalt "Digital Tinglysning", hvor jeg jobbet mye med Web services og den slags på Java-plattformen.

Arbeidsplassen til Mikkel. 📸: Privat
Arbeidsplassen til Mikkel. 📸: Privat Vis mer

Hva jobber du med akkurat nå? 🛠️

De siste årene har vi i teamet utviklet en distribuert løsning for innsamling, prosessering, analyse og aggregering av trafikkdata. Løsningen kjører på JVM-plattformen og samler inn enkeltpasseringer for kjøretøy fra rundt 2300 tellepunkter fordelt over Norge, hvor det ligger induktive sløyfer i vegbanen som registrerer kjøretøyer og lagres på en boks/datalogger i vegkanten.

Hver enkelt passering blir via en distribuert serverløsning overført og lagret i Elasticsearch med egenskaper som felt, retning, lengde, kjøretøystype og så videre. Selve softwaren som kjører på dataloggerne i vegkanten har vi ikke laget, men vi integrerer med dem via en protokoll som heter OPC-UA.

Backendløsningen som integrerer med dataloggerne er skrevet i Java/Scala og med Akka Actors for å håndtere stateful connections mot dataloggerne. Løsningen er sharded ved hjelp av Akka Sharding sånn at koblinger mot målestasjoner kan balanseres ut over et antall noder etterhvert som det kommer flere målepunkter, og det skaleres med flere noder. Samt at noder kan ta over connections fra andre noder om de går ned.

På toppen av innsamlingsløsningen har vi laget en rekke applikasjoner samt REST- og GraphQL-API-er skrevet i Java, kjørende enten med Spring Boot eller plain embedded Jetty og JAX-RS/Jersey. Disse appene har ulike roller, for eksempel for firmwareoppradering og igangsetting av nytt utstyr/målepunkter, kvalitetskontroll på overføring av passeringer, samt aggregering og beregning av høyere nivå produkter på toppen av enkeltpasseringene.

«På toppen av innsamlings-løsningen har vi laget en rekke applikasjoner, samt REST- og GraphQL-API-er skrevet i Java.»

Et eksempel er f.eks. Vegtrafikkindeksen (prosentvis endring i trafikk per måned i forhold til året før aggregert på ulike vegtyper, fylker/regioner, størrelse på kjøretøy). Det beregnes også volumetall per time og døgn fordelt på felt, retning, lengdeklasse osv. for alle målepunkter samt trafikktall som ÅDT og MDT (årsdøgntrafikk og månedsdøgntrafikk). Frontend/SPAs er skrevet i React, noen med Redux, andre med en tidlig implementasjon av Flux pattern (løsningen har etterhvert noen år på baken 😅).

Løsningen kjører på infrastruktur hos Drift i Statens vegvesen, men det meste av provisjonering, konfigurasjon og deploy blir gjort av teamet selv med verktøyer som Puppet, Chef og Ruby. Som overvåking og varsling bruker vi Prometheus og Alert Manager med push til Slack. Vi bruker Grafana for systemmetrikker og dashboards samt Kibana for mer forretningsnære visuliseringer. Det har vært viktig å få på plass en robust og pålitelig innsamlingsløsning med trafikkdata med kjent kvalitet, så det har ikke vært så mye å vise frem hittil.

Men det er begynt nå med "Trafikkdataportalen" - www.trafikkdata.no - som er skrevet i React, Apollo og D3 for visualiseringene. Dataen til appen leveres fra et GraphQL API som enda ikke er offentlig lansert, men det er tanken at utviklere skal kunne bruke det for å bygge løsninger eller apps på de data Statens vegvesen samler inn og deler. 👌

Det nyoppstartede prosjektet jeg jobber på nå kalles "Stordataplattformen Saga". Saga er den norrøne gudinnen for visdom, “hun som ser alt og vet alle ting” – en passende beskrivelse på en løsning som tar mål av seg å være et samlingssted for å hente inn, analysere og dele data fra mange kilder.

Visjonen til Saga er å bidra sterkt til å gjøre Statens vegvesen til en datadrevet organisasjon rustet til å møte utfordringene i fremtidens transportsystem ved å tilrettelegge for effektiv og enkel dataflyt og gi brukerne gode muligheter for analyse og deling av data internt og eksternt. Prosjektet er i startfasen, hvor en del av arbeidet er å finne ut hva en slik plattform skal kunne tilby og hvordan den skal bygges.

Kontorområdet der Mikkel og kollegaene sitter. 📸: Privat
Kontorområdet der Mikkel og kollegaene sitter. 📸: Privat Vis mer

Hvordan ser en typisk arbeidsdag ut for deg? ☕

Dagen starter med en hjemmelaget cortado på espressomaskinen. Alltid! Deretter hopper jeg på sykkelen i full fart og ofte i seneste laget til jobb. 🙈

På Trafikkdata-prosjektet startet dagen ofte med å se over pull requests. Alle endringer kjøres som PRs på GitHub, og det er alltid en som ser over koden, gjerne i samarbeid med den som har laget endringen for å gjøre det mer effektivt og raskere forstå hensikten med endringen.

Da blir det ofte mer fokus på den generelle struktur på endringen og ikke bare nitpick eller småkommentarer. Ellers er arbeidsoppgaven koding og sparring med de andre på teamet. Prosjektet kjøres med en smidig kanban-inspirert prosess med daglig standup i teamet kl. 11 og et demo/statusmøte på fredager med fremvisning av hva som er gjort og rullet ut i prod siden forrige fredag.

Teamet er samlokalisert med produkteier og fagsiden, så det er sjeldent behov for store møter og avklaringer, de kan ofte tas direkte, noe som er veldig greit som utvikler og for produktiviteten. Det brukes også Slack ganske mye til diskusjon og avklaringer og deling av interessant informasjon. Ellers er det "groomingmøter" ved behov, hvor brukerhistorier med høyest prioritet i backloggen detaljeres ytterligere så de er klar for å bli dratt i arbeid. Prosjektet har generelt vært "green-field" prosjekt, hvor vi har tatt stilling til ganske mange ting helt fra overordnet arkitektur til bruk av enkelte rammeverk eller biblioteker.

«Vi har en tendens til å bare stoppe opp og ta diskusjoner og beslutninger med én gang.»

I perioder med mange av disse prosesser på tvers av to fysisk plasserte team (vi var et team i Oslo og Trondheim tidligere) har jeg som tech lead fasilitert "teknisk hjørne"-møter hver annen fredag. Her har vi tatt opp diskusjoner rundt typiske cross-cutting concerns f.eks. prinsipper for overvåking og logging eller folk har vist frem kule ting de har gjort med f.eks. et nytt bibliotek som vil kunne gavne oss i prosjektet.

Ellers har vi en tendens til å bare stoppe opp og ta diskusjoner og beslutninger foran f.eks. et whiteboard med én gang når folk trenger hjelp eller innspill. Typiske arbeidsoppgaver ellers er å rulle ut sin egen funksjonalitet når det er merget, samt at vi har et "ukens drifter"-ansvar som går på rundgang i teamet, hvor oppgavene er å yte support, reagere på varsler fra overvåking og generelt sikre at løsningen kjører smooth.

Ellers er det jo også livet i Bekk utenom prosjekt hos kunde med ulike faglige/sosiale arrangementer, så noen dager kan være både hos Bekk og hos kunden. Vi har blant annet faggruppemøte på rundt 3 timer ca. en gang i måneden med f.eks. hackatons eller lyntaler/foredrag og avdelingsmøter også en gang i måneden. Begge ofte med et sosialt arrangement etterpå.

Hva synes du er de mest spennende språkene, rammeverkene eller teknologiene akkurat nå? ✨

Jeg har holdt meg mest på JVM-plattformen gjennom årene og hatt en tendens til å interessere meg for utvikling på backend. Jeg har pint meg selv med utfordringene rundt større distribuerte systemer og egenskaper som skalerbarhet, robusthet, feiltoleranse, overvåking og driftbarhet.

Et bibliotek jeg har lekt med og kan anbefale rundt robusthet er resilience4j som støtter f.eks. å lage Circuit Breakers på en enkel måte. Et tema jeg har interessert meg for i det siste er Observability (metrics, traces, logs). Jeg synes Prometheus er bra for metrikker (og er med i Cloud Native Foundation), og med bruk av Spring Boot og Micrometer får man et Prometheus-endepunkt ut av boksen.

Legger du til Grafana for visualiseringer og AlertManager med hook til Slack, så er du kommet ganske langt på overvåking og varsling. Distribuert tracing er et annet område jeg har utforsket etter vi også har kastet oss på trenden med mikrotjenester 😅 Eller ihvertfall har flere tjenester som avhengigheter av hverandre, og hvor det er utrolig nyttig å kunne følge en request gjennom alle disse ved feil og jobbing med ytelse.

Jeg var på QCON i London i mars, og her var det stort fokus på "operationalizing microservices", og en god del foredrag om observability, blant annet en keynote om tracing med Ben Sigelman (CTO hos LightStep og tidligere Googler og utvikler på Dapper).

Jeg har satt opp tracing med Zipkin og instrumentert eksisterende Spring Boot applikasjoner med Spring Cloud Sleuth. Zipkin er enkelt å få opp å kjøre hvis du allerede er i Java-land, men er du i Kubernetes-land ville jeg nok heller ha sett på OpenTracing, Envoy-proxy og Jaeger (eller evt. LightStep som er en SaaS for tracing).

På språksiden synes jeg at Kotlin virker veldig bra, men har ikke hatt anledning til å bruke det i prosjekt enda. Det virker til å ha blitt veldig populært, og det integrerer bra med Java (f.eks. i forhold til Scala som jeg tidligere har sett ganske mye på). Hvis du er stuck med Java av ulike årsaker, så kan biblioteker som cyclops-react.io eller vavr.io (tidligere Javaslang) gi språket et løft og gjøre det enklere å kode funksjonelt i Java med blant annet immutable collections, reactive og asynkron kode samt bedre abstraksjoner for mer funksjonell kode som en Try monad og så videre.

Ellers lever jeg litt i en skyboble akkurat nå og synes personlig at Google Cloud Platform og deres serverless/managed services virker veldig tiltalende for å bygge en sånn stordataplattform. Det frister å bruke minst mulig tid på oppsett og konfigurasjon av instrastruktur og komponenter, og heller bruke allerede ferdige og driftede tjenester som Pub/Sub, Cloud Dataflow, BigQuery og Data Studio.

Hva er du mest stolt av å ha laget? 🏆

Hvis jeg skal velge én ting, så krever det en liten forhistorie 😅 På min første arbeidsdag i Bekk, og i Norge etter jeg flyttet hit i 2011, ble jeg hentet i bil tidlig på morgenen av tre nye kolleger fra Bekk.

Vi skulle på roadtrip til vår kunde, Normatic, i Nordfjordeid. De driver med en automasjonsløsning og styringssystem innenfor blant annet bygg og anlegg og vann/avløp. Vi skulle hjelpe med å modernisere en webbasert løsning for prosesskontroll og overvåking av diverse utstyr. Med i bilen var Jonas Follesø som nå er CTO i Blueye Robotics. Vi snakket litt løst og fast om softwareutvikling, og jeg fortalte om et fag jeg hadde på masterstudiet om lexing/parsing/compilere samt et prosjekt, hvor vi laget en miniversjon av programmeringsspråket Scheme ved hjelp av en parser-generator og evaluering skrevet i C#.

Jeg syntes egentlig det var litt vanskelig, men det sa jeg selvsagt ikke 😇 Jonas sa at det hørtes bra ut, for akkurat slik kompetanse kunne det faktisk bli bruk for i prosjektet. Oops tenkte jeg! Sant var det. Etter en stund satt jeg og implementerte en grammar og lexing/parsing ved hjelp av en compiler-compiler kalt Coco/R.

«Jeg syntes egentlig det var litt vanskelig, men det sa jeg selvsagt ikke.»

Normatic brukte nemlig et lite programmeringsspråk med noen få statements som if/else, enkle matematiske beregninger og variabler i konfigurasjonen av prosessovervåkingsbilder. F.eks. for å konfigurere varsler og farger på skjermen, og dynamisk kunne evaluere uttrykk basert på verdier fra variable på en OPC-server. Løsningen parset disse statements fra konfigurasjonsfiler og bygget et AST (abstract syntax tree).

Dette ble overført via JSON til en klient i Silverlight som viste et prosessbilde og som inneholdt selve evaluatoren og et variabelregister som pekte på navn på signaler på en OPC-server (de ulike tilstande på f.eks. hastighet på en vifte eller om en bryter var på eller av). Når det kom endringer på disse signaler, så ble de konfigurerte uttrykk evaluert og skjermen oppdatert med f.eks. en animasjon eller varselslampe.

DET hadde jeg aldri trodd jeg skulle få bruk for som konsulent 😀 Det skal forresten nevnes at det var litt av en bratt start på jobben i Norge sånn dialektmessig! Det var kolleger fra Finnmark, Voss og Namsdalseid, samt en rekke folk fra Stryn og Nordfjordeid hos kunden 😅

Hva er det vanskeligste ved å være utvikler? 🤷

Jeg synes det er å balansere lysten til å bruke ny og spennende teknologi vs. eldre og mer velkjent teknologi. Det skjer så utrolig mye spennende innenfor alle områder av softwareutvikling, og det er fristende å ta i bruk nye og "bedre" ting.

Vi tror jo ofte noe nytt er bedre, men det er først når man virkelig har jobbet med noe i dybden at man forstår dets styrker og svakheter. Det er mulig det er litt mer utbredt i konsulentbransen fordi man ofte(re) starter på nytt når det startes på nye prosjekter.

Det er jo en viss risiko forbundet med å bruke nyere og mindre avprøvet teknologi - med tanke på levedyktighet, vedlikehold, oppgradering og tilgang på kompetanse. Det er ikke så farlig med mindre biblioteker og den slags, som kan byttes ut forholdsvis lett.

Hele programmeringsspråk er litt verre, og i en periode var det veldig hype rundt ulike NoSQL-databaser. Man skulle for guds skyld ikke bruke en relasjonsdatabase 😉 Jeg har selv ganske mye erfaring med f.eks. Elasticsearch og MongoDB, og jeg kan ikke med hånden på hjertet si at det var en perfekt erstatning for en RDBMS når vi valgte å innføre det.

Jeg vil dog si at det nok er blitt enklere å teste ut nye språk, rammeverk og biblioteker ettersom man er gått vekk fra store, tett koblede monolitter til mindre samarbeidende services, autonome team og mer løst koblede løsninger som rulles ut kontinuerlig og hver for seg.

Hva synes du norske utviklere bør bli flinkere på? 🙋

Det er et godt spørsmål. Jeg synes generelt norske utviklere er utrolig flinke! Faktisk ble jeg litt overrasket over hvor mye faglig aktivitet, meetups og konferanser det var Norge da jeg flyttet hit i 2011. Og hvor mye det har eksplodert siden.

«Det er mulig vi utviklere bør bli flinkere til å ikke bare kaste oss over ny teknologi.»

Jeg er rett sikker på det var ganske mye mer enn i Danmark på den tiden. Det var mye fokus på smidig, metoder generelt, kodekvalitet, software craftmanship, testing, TDD, BDD osv.

Det er jo kjempebra, men mulig det også er det som tvinger frem den lysten til å ta i bruk ny teknologi, arbeidsprosesser og metoder. Det er mulig vi utviklere bør bli flinkere til å ikke bare kaste oss over ny teknologi for alt det er verdt, men heller vurdere om det er bedre å bruke noe litt eldre og avprøvet teknologi, hvor vi kan bygge på erfaringene og utvikle ting mer effektivt?

Det er jo en kostnad og risiko å bygge noe med teknologi man er mindre erfaren med.

Hva liker du å gjøre når du ikke jobber? 🕹️

Jeg spiller en del squash. Ellers er jeg ganske hektet på stisykling og toppturer på ski, og har vært mange spektakulære plasser i Norge med begge aktiviteter. Og noen ganger på stisykkelferie f.eks. i Sveits og Finale Ligure i Italia.

Foto er også ofte en del av dette, og jeg hadde en periode med seriøs nerding av fototeknikk og massiv lesing av reviews før jeg kjøpte kamera og linser. Jeg har en stor lyst til å lære meg nye ting og har nok en undersøkelseslyst litt utover det vanlige.

Spør meg om hva som helst innenfor et område jeg har hatt interesse for, og jeg kan liste opp modellnavnene, fordeler/ulemper og alternative produkter. Faktisk er jeg (ofte slitsomt) betatt av å lære meg hvordan ting fungerer, lese reviews, kunne fikse/reparere ting selv, og perfeksjonere ting.

Det gjelder alt fra espresso-nerding, prepping av ski til å kunne mekke det meste på f.eks. min stisykkel selv f.eks. bleeding av bremser og demperservice. To ting dere kan tenke jeg har for lite av med de interesser; tid og penger 😇