There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.

C. A. R. Hoare

Design er en pågående jobb som programmerer. Det handler om å ta stilling til hvilke undersystemer som kan skilles ut som selvstendige komponenter, hvordan disse skal kommunisere, og på et lavere nivå, hvilke datastrukturer og abstraksjoner vi trenger. Målet med ethvert design er å finne en robust løsning som slår en god balanse mellom fleksibilitet, og kost i form av hvor lang tid det tar å komme i mål.

Et godt design tåler å få nye, uventede krav stilt mot seg uten å kollapse; altså at man må skrive om hele eller store deler av løsningen for å komme i mål. Et godt design tar også hensyn til at systemet skal driftes og leve videre etter at det første utviklingsprosjektet er over.

Mange Kodemakere har hatt rollen arkitekt i prosjekter, og i denne rollen har man det formelle ansvaret for det overordnede designet i systemet. Også de av oss som ikke har hatt den formelle rollen arkitekt har mange tanker og meninger om programvaredesign, noe som både kommuniseres til våre omgivelser i det daglige såvel som gjennom foredrag på konferanser og andre fagsamlinger.

Våre anbefalinger

Simple Made Easy
Anbefalt av August, Christian og Magnar

Rich Hickey, oppfinneren av Clojure og Datomic, snakker om forskjellene på «Simple» og «Easy». Det er stor forskjell på «vanskelig», som er subjektivt (Russisk er vanskelig fordi du ikke kan det), og «simpelt», som er objektivt (spagetti-kode er vanskelig å lese fordi det er sammenvevd). Denne presentasjonen har allerede rukket å bli rene Woodstock-legenden, og forklarer godt hovedpoengene med Clojure uten en eneste linje kode.

React: Rethinking best-practices
Anbefalt av Magnar og Christian

Pete Hunt, en av hodene bak JavaScript UI-rammeverket til Facebook og Instagram, React, forteller om tankene bak. Foredraget fra JSConf.eu 2013 utfordrer en del etablerte sannheter og presenterer en måte å tenke på web-frontend-programmering på som sammenfaller med klassisk UI-programmering og som virkelig fokuserer på separation of concerns.

On the Spectrum of Abstraction
Anbefalt av Magnar

Rich Hickey har noen fantastiske talks. Han snakker om generelle prinsipper, og gir deg ofte noen nye konsepter og ord du kan bruke til å tenke med rundt programmering.

Det er ikke ofte jeg ser talks av andre enn Hickey som har denne typen øye-åpnende innhold, men dette er en. Det er litt knot og kluss i starten, men det tar seg veldig opp. Han introduserer noen spissede begreper (power vs usefulness / properties) og bruker de til å snakke om abstraksjonnivåer på en veldig interessant måte. Mye godt tankemateriale her. Anbefales!

Programming Antiobjects
Anbefalt av Kristoffer

Et foredrag på OOPSLA-konferansen i 2006 satt tradisjonell objektorientering og simulering litt på hodet. Istedenfor å la objektene leve sitt eget liv og styre seg selv, kan man gi liv til omgivelsene rundt dem. Lukten av Pacman setter seg i spillbrettet, og det er brettet som styrer spøkelsene etter Pacman. Lukten av fotballen sprer seg i gressmatten, og spillerne blir sendt i retning av den. Oppgaven deres blir å sparke ballen vekk fra stanken fra det andre laget. Det gir interessante omganger fotball, særlig hvis det er flere baller på banen.

The Future of JavaScript MVC Frameworks
Anbefalt av Christian

David Nolen, Clojurescript-superstjerne, forteller om sitt ‘Om’, Clojurescript-API over Facebook’s React. Om går enda noen skritt fra hva React tilbyr ved å servere hele pakka med immutable datastrukturer og et funksjonelt API. Artikkelen viser samtidig hvordan dagens mest populære MVC-rammeverk for JavaScript er langt fra å tilby en tilfredstillende løsning på problemene vi som frontendutviklere møter.

Våre foredrag

Magnar snakker hva, hvorfor og hvordan om Pure Functions, i et utbrudd av entusiasme etter å ha jobbet med en kodebase basert på disse prinsippene et par år.

En applikasjon koster mer å forvalte enn å utvikle. Likevel blir de fleste kodebaser optimalisert for arbeidet gjort i prosjektfasen før prodsetting. Christin kommer med noen tanker rundt hva vi kan gjøre annerledes for å gjøre applikasjoner lettere å forvalte.

Kjapp gjennom gang av sukksesser og utfordringer med å innføre elektronisk søknad for Bostøtte

Bør staten drive med softwareutvikling? Hva skjer når man setter utvikling ut på anbud?

Smidige utviklere spør ikke om råd

Smidig utvikling handler om å være reaktiv fremfor proaktiv. Istedenfor å analysere i forkant, validerer man antakelsene sine fortløpende. Vi må slutte å be om avklaringer i forkant og heller test ut teoriene våre og sjekke om de faktisk fungerer i virkeligheten.

De første delleveransene skal være stygge

I smidig produktutvikling er det viktig med fortløpende validering av løsningen. Man vil finne potensielle feil raskt. Man skal ikke vente med at applikasjonen er ferdig før man viser den. Det at de første leveransene er mangelfulle er en del av den nødvendige prosessen og må ikke sees som feil.

Architects in Scrum is like mayonnaise in cake

Hvorfor hierarkisk rollefordeling med ledere og arkitekter ikke fungerer så bra med smidige prinsipper.

Det er de smarteste folkene som innfører byråkrati

Alle klager over byråkrati, så hvordan har det seg at vi til stadighet innfører mer av det?

JavaScript design and architecture

En liten inspirasjonsprat om å finne gode abstraksjoner for frontend-programmering

Test-driven JavaScript Development

En praktisk gjennomgang av TDD i JavaScript. Foredraget er en times live-kode-sesjon der Christian lager et autocomplete/type-ahead søk, test-first.

Vår fri programvare

  • UseCase - Strukturerte abstraksjoner for ikke-triviell programflyt. Biblioteket ble opprinnelig skrevet for å redusere kompleksiett i Ruby on Rails-applikasjoner, men er ikke spesifikt avhengig av Rails. Biblioteket reduserer koblinger mellom modeller og kontrollere, og kan potensielt redusere kompleksiteten i begge betraktelig.

Våre blogginnlegg

Lag ditt eget rammeverk

Ja, det er en oppfordring. Jeg mener for guds skyld ikke at du skal lage et nytt rammeverk som andre kan bruke, men lag et til deg selv. Sett opp et stilas som passer til det du bygger.

Men ikke med en gang.

Samspill mellom generiske UI-komponenter

I forbindelse med bloggposten om en enkel frontendarkitektur som funker, spurte Ove: «Hvis du har en tekstboks og en knapp, hvem har ansvaret for å ta verdien fra tekstboksen og sende den til eventbussen når man trykker på knappen?» Det er et betimelig spørsmål med noen interessante detaljer.

Når databasemodellen blir domenemodellen

Domene-kode kan med rette kalles kjernen i applikasjonene vi utvikler, men den gjør ikke mye nytte for seg uten støttende infrastruktur, som lagring av data og kommunikasjon med andre systemer.

Men hva skjer når infrastrukturen er med på å forme domene-koden?