I år skal Kodemaker prøve Elixir og Erlang

- Tror grunnen til at de ikke blir brukt skyldes mangel på erfaring, forteller utviklerne. Her er alt de har slutta med, starta med og planlegger i 2020.

Kodemaker-kodere Eivind B. Waaler, Stian Cornelis Alsos, Fredrik Aubert, Anders Furseth, Sindre Grønningen og Frode Nerbråten har oppsummert 2019, og spår litt om 2020. 📸: Kodemaker
Kodemaker-kodere Eivind B. Waaler, Stian Cornelis Alsos, Fredrik Aubert, Anders Furseth, Sindre Grønningen og Frode Nerbråten har oppsummert 2019, og spår litt om 2020. 📸: Kodemaker Vis mer

Med sine rundt 25 utviklere er Kodemaker langt fra et stort konsulentselskap. Men de gjør seg bemerka, med ivrige, erfarne og ikke minst engasjerte utviklere, som blant annet har bidratt med gode blogginnlegg her på kode24.

Vi ville derfor ha dem med i vår Kodeåret-serie, hvor vi ber norske utviklere oppsummere året som gikk og spå året som kommer.

- Da vi satte oss ned for å snakke om teknologier, fant vi fort ut at hva vi liker og bruker til daglig varierer fra person til person, og kanskje viktigere: At vi egentlig er mer opptatt av teknikker og prinsipper enn selve teknologien, forteller Stian Cornelis Alsos til kode24.

- For eksempel er vi enige om at bruk av funksjonell programmering har større effekt på kvalitet og effektivitet enn programmeringsspråket man bruker. Og visste du at organisasjonsstruktur har større innvirkning på programvarekvalitet enn typiske metrikker som testdekning, kode-kompleksitet og avhengigheter?

Men sammen med Eivind B. Waaler, Fredrik Aubert, Anders Furseth, Sindre Grønningen og Frode Nerbråten har de likevel synset litt om trendene fra 2019, og spår noen trender i 2020.

Hvilke teknologier begynte dere å bruke i 2019? ✨

På programmeringsspråk-fronten ser vi at det som regel er stuerent å bruke andre språk enn de mest tradisjonelle.

På flere store prosjekter har Kotlin tatt over for Java som førstevalg av språk på JVM. Vi har også snust på å bruke Swift som backend-språk på prosjekter som lager iOS-applikasjoner. Her brukes jo stort sett Swift til app-utviklingen, og man kan ha glede av å bruke samme språk på backend.

«På frontend-siden ellers ser TypeScript ut til å ha inntatt tronen som nytt standard-språk.»

Kodemaker har i mange år vært forkjemper for bruk av henholdsvis Clojure og ClojureScript som backend- og frontend-språk. Clojure er et språk som rendyrker mange av prinsippene vi holder høyt: Funksjonell programmering, persistente (immutable) datastrukturer og det faktum at kode og data er to sider av samme sak. Vi har mange svært vellykkede prosjekter basert på denne teknologien, og flere Kodemakere har startet med Clojure i løpet av året som har gått.

På frontend-siden ellers ser TypeScript ut til å ha inntatt tronen som nytt standard-språk. Det er et solid språk som gir utviklere mye av det de har savnet i JavaScript med tanke på typesjekking/kompilering og syntaks. I tillegg er det enkelt å komme i gang med – man kan skrive kode som om det var JavaScript og ta inn nye biter etterhvert som man lærer seg mer av språket. Verktøystøtten er også glimrende – noe som gjør TypeScript lett å bruke uten å knote rundt med umodne verktøy. En sjelden egenskap for et relativt ungt språk.

Vi kommer ikke utenom React når vi først er inne på frontend. Dette rammeverket brukes på veldig mange prosjekter – også i kombinasjon med ClojureScript gjennom biblioteker som Reagent.

Den store nyheten for React det siste året har vært bruken av hooks – et velkomment tillegg som gjør at man slipper å skrive klasser i det hele tatt. Vi har diskutert hooks en del internt og noen er litt skeptiske og mener at de kanskje fører til mer tilstand lokalt i komponentene enn før. Men vi ser at hooks kan bidra til ryddigere komponenter, samtidig som det er deilig å slippe masse recompose-kode for å unngå klasser.

Fra et ClojureScript-perspektiv tilfører ikke hooks noe spesielt. Her er React allerede brukt kun som rent rendering-rammeverk, mens tilstand styres utenfor. Hvordan vi forholder oss til tilstand i frontend-applikasjoner er alltid en spennende diskusjon – og igjen mener vi at det å gjøre tilstand “riktig” er viktigere enn hva slags teknologi som muliggjør det.

Vi må også nevne Datomic. Det er en litt utradisjonell database som kobler persistente (immutable) data med tid, og dermed blant annet lar deg reise bakover i tid. Flere i Kodemaker har brukt og snakket varmt om Datomic i mange år, og noen har brukt det for første gang i året som gikk. Har man behov for å se hvordan dataene så ut på et gitt tidspunkt – noe man overraskende ofte har – så er dette en teknologi som leverer det rett ut av boksen.

Hvilke teknologier slutta dere å bruke i 2019? 💩

Vi har allerede nevnt at Java oftere velges bort til fordel for Kotlin, og vi ser stadig færre prosjekter som etterspør ren Java. Vi opplever også at kunder prøver seg på språk som går helt utenom JVM, som for eksempel Go, Elixir og Python.

På rammeverk-fronten velger vi i Kodemaker bort større rammeverk som Spring og Grails, og går heller for mer spesialiserte lettvektsalternativer. Et eksempel er Micronaut – som vi har tatt i bruk på et par prosjekt.

«På rammeverk-fronten velger vi i Kodemaker bort større rammeverk som Spring og Grails.»

Mindre rammeverk gir oss gjerne egenskaper som gjør dem bedre egnet for deployment til skyen, som for eksempel rask oppstartstid og lavt minneforbruk. I mange tilfeller velger vi heller å sy sammen et knippe spesifikke bibliotek enn å bruke et rammeverk. Da får vi kun den funksjonaliteten vi trenger, mer fleksibel programflyt og vi slipper å være avhengig av release-takten til rammeverket for å oppgradere transitive avhengigheter.

Innen frontend ser det endelig ut til at det er mer eller mindre slutt på å skrive egne stylesheet-filer (CSS, SASS, LESS og så videre). Det er veldig deilig å slippe digre CSS-filer hvor halvparten av stilene er utdaterte, men ingen tør å fjerne dem i frykt av at de er i bruk et sted man ikke har fått med seg.

Både på TypeScript/Javascript- og ClojureScript-prosjekter bruker vi nå utelukkende teknologier som lar oss skrive CSS/stiler som en del av koden til komponentene. Det gir ryddigere kode som er mye enklere å vedlikeholde.

Utover dette ser vi at bruken av Internet Explorer i mange prosjekter er tilnærmet lik 0, noe som gjør at vi får større spillerom til å ta i bruk nyere webstandarder.

Hvilke teknologier antar dere å begynne å bruke i 2020? 🔮

I året som kommer tror vi det blir enda mer bruk av Serverless, samt at mer og mer av det vi lager flyttes over i skyen. Ingen sjokkerende påstand det kanskje, med tanke på at det både er billigere og bedre enn alternativene – så fremt man gjør ting riktig, selvsagt.

Elixir er et språk flere i Kodemaker har hatt lyst til å ta i bruk en stund nå. Språket er svært godt egnet om man vil skrive kode med stor grad av asynkronitet og samtidighet. Det kjører på Erlang VM – en plattform laget for distribuerte systemer med krav til kjappe responstider og god kontroll på feilhåndtering.

Vi har jobbet med actor-rammeverk som Akka på JVM tidligere – noe som er inspirert av Erlang, men det er ekstra gøy å få jobbe med “originalen”.

Vi tror grunnen til at Elixir og Erlang ikke blir brukt mer skyldes mangel på erfaring i det norske markedet. Dette har vi tenkt å gjøre noe med, så stay tuned for erfaringsrapporter fra oss.

Om dere bare skulle lært dere én ny teknologi for å bli klare for 2020, hvilken ville det vært? 💡

En ting vi håper å kunne teste ut er mer bruk av maskinlæring.

Maskinlæring er jo egentlig et eget fagfelt og fremstår kanskje litt skremmende, men de siste årene har det kommet mange ferdig trente nettverk som tilbyr funksjonalitet som en tjeneste i skyen. Det betyr at du i en del tilfeller ikke lenger trenger dyp kunnskap om maskinlæring for å dra nytte av denne type teknologi. Eksempler kan være å bruke en tjenester for bildegjenkjenning for å velge et fornuftige utsnitt i bilder av ansikter, eller tjenester for kategorisering av bilder.

Vi ser også at verktøystøtten for kryss-plattform maskinlæring har blitt mye bedre. Det er nå blitt mye lettere å trene et nettverk i skyen, og bruke den ferdigtrente modellen i browseren eller i mobil-appen.

For et år siden utviklet vi første utgave av dart-systemet til Oche – basert på mer tradisjonell bildeanalyse. Det kunne vært veldig spennende å jobbet med noe lignende hvor vi også fikk muligheten til å teste ut maskinlæring som alternativ eller eventuelt i kombinasjon med mer manuell bildeanalyse.

Hva tror dere blir bransjens største utfordringer i 2020? 🔥

Med GDPRs inntog har vi utviklere i langt større grad blitt ansvarliggjort at programvaren vi lager etterlever reglene forbundet med personvern. En utfordring vi ser her er manglende kunnskap hos utviklere og produkteiere.

Facebook Pixel er et eksempel på en tracker som ofte tas i bruk som bryter reglene for tracking om man ikke ber om eksplisitt tillatelse fra brukerne. Motivasjonen er typisk at man ønsker å få statistikk på hvor langt brukere kommer i for eksempel en kjøpsprosess på en nettside. Disse dataene er knyttet opp mot en personlig profil på Facebook, og dermed kan Facebook bruke og selge disse dataene til tredjeparter som måtte ønske å kjøpe dem.

Dessverre vil vi nok også fortsette å se prosjekter som gaper over altfor mye på én gang. Drøssevis av utviklere, millioner av kroner, detaljerte planer og “big bang”-leveranser. Det er fort gjort å gå i fella og tenke at store komplekse domener trenger store komplekse løsninger. Selv om det er utfordrende både organisatorisk og teknisk så må vi dele opp de store prosjektene i mindre deler slik at vi kan begynne å levere verdi til brukerne med én gang – ikke først om 10 år.

«Det er fort gjort å gå i fella og tenke at store komplekse domener trenger store komplekse løsninger.»

For å få til dette må vi fordele ansvaret på små autonome team som leverer hyppig og som ved behov kan korrigere kursen underveis i prosjektet. Det finnes en del forskning som også understøtter dette budskapet. I boken Accelerate tar forfatterne for seg denne forskningen og ser på hvilke faktorer som faktisk driver effektivitet og kvalitet i utviklingsprosjekter. Boken er et kjærkomment tilskudd til en ung bransje som mangler en felles forståelse av hvordan man lager god programvare. Kanskje noe å lese i løpet av 2020?

Til sist er det vel også på sin plass å nevne klima. Mange føler at 2019 var året da man virkelig begynte å skjønne alvoret – og 2020 kan kanskje bli året da alle begynner å ta en større del av ansvaret? For eksempel kan vi tenke gjennom hvor mye energi løsningene vi lager bruker – og kanskje “spare” noen watt på hver klient eller cloud-server som er i bruk?

Som teknologer er vi også storforbrukere av ny teknologi – og her kan vi gjøre masse. Kanskje bruke datamaskinene et par år ekstra før de byttes ut? Ikke bytte mobil hvert år? Ikke kjøpe gadgets fra Kina som bare blir liggende i en skuff etter noen uker... Vi kan reise mindre i jobbsammenheng – det er for eksempel mye bra konferanser i Oslo. Og sikkert tusen andre ting.

Her kan vi som teknologer gå foran som gode eksempler – hva med en utfordring til bransjen for å se hvem som kan gjøre mest?