Morn!

God morgen! Litt på siden, men her er enda en liten bloggpost om NATS, denne gangen om key/value storen. Kommer snart et Clojure-bibliotek for dette nydelige systemet 😄 https://parenteser.mattilsynet.io/nats-kv/

Dagens lille design nøtt: Den beste måten å designe for edge-caser er å ikke.

Jeg har angret på at jeg har “prøvd å være for lur” mange ganger. Seinest i går. Da brukte jeg to timer på å fjerne en “for bred” abstraksjon. Jeg tror jeg aldri har angret på at jeg gikk for å “løse problemet jeg har akkurat nå“.

Samtidig er det noe i hvordan Rich designer åpne systemer. Noe med hvilke funksjoner som bør ta parametre (feks funksjoner som jobber med en database-tilkobling). Jeg klarer ikke helt sette fingeren på akkurat hva det er. Men det handler kanskje mer om å plukke ting fra hverandre enn å forutse edge-caser.

her kan typesystemer være litt vriene og. Når jeg skal kjøre et kjapt eksperiment i TypeScript, må det også types. Prøver å ungå å bruke any og unknown og sånt, for det er så fort gjort at det blir værende igjen. Så da ender man opp med å designe typene og dataflyten før du har implementert noe

skulle ønske alle typesystemer kunne toggle av og på “lekemodus”. Ikke lov å sjekke lekekode inn i prod, men fint å kunne utvikle typeusikker kode og heller fase inn typer senere

I Go/Haskell liker jeg å se etter muligheter til å bruke interfaces (Go) og typeklasser (Haskell) når jeg skal skrive kode som jeg ikke vil at skal være avhengig av konkret implementasjon. Men enig, jeg synes dette er lettere å få til feks i Clojure enn i feks Go.

Men det er en liten luregreie her. Hvis du bygger bottom up, dvs små byggeklosser som kan komponeres for å løse det vanlige use-caset, så kan man løse edge-casene ved å bygge litt anderledes med de samme byggeklossene. Men hvis du begynner top-down, så har du kanskje ingen mindre byggeklosser og du må løse edge-casene dine i den store top-down byggeklossen. Som da blir veldig komplisert, og ikke noe gøy å bruke

Meg når jeg programmerer i Clojure:

Morn!