Det kommer jo veldig an på størrelsen av problemet, men en av mine favorittmåter å flate ut data er ved å dytte dem inn i Datomic. Ref https://parenteser.mattilsynet.io/flate-data/

eg har brukt zippers litt: https://www.kodemaker.no/blogg/2020-05-zippers/

greit verktøy det (av og til)

> Datomic jaaaaaaa. Sant! Dette mener jeg dere allere har snakket om, lurer på om dere nevnte “Putt det i Datomic for å gjøre grafspørringer” på Clojure-meetupen i fjor sommer. Og dere gjør vel allerede dette på http://kodemaker.no og på den statiske nettsiden dere har laget i mattilsynet. Jeg prøvde Datomic såvidt forrige uke; det gikk mye kjappere å komme i gang med com.datomic/peer {:mvn/version "1.0.7075"} og datomic:mem:// enn jeg trodde. Nesten så man ikke trenger Datascript hvis man uansett er på en JVM?

> Zippers Godt poeng. Det har jeg aldri fått brukt “in anger”. God unnskyldning til å endelig lære seg. Takk for reveransen. Har lest den før, mulig jeg må lese en gang til!

@christian767 og jeg satt nylig og jobbet med en hel del data, som bare skulle være midlertidig. Det var litt styrete, men gikk helt greit. Dagen etter hadde Christian slengt dataene inn i en midlertidig Datomic database istedenfor. Det var hinsides mye bedre. Ikke bare jobbet vi raskere, men det var så mye lettere å få til ting at vi også testet flere teorier, og gravde i ting vi ikke ellers ville tatt oss tid til.

kjørte dere den databasen i-minnet, eller gikk dere for persistens av noe slag? Mulig jeg kommer til å prøve noe selv, og er litt usikker på akkurat den biten. Tenker at i-minne kanskje er greit hvis man lett klarer å reprodusere det man skal lokalt. Så kan man eventuelt serialisere til filer igjen fra datomic hvis man vil det.

Starta med data i minnet, og så flytta vi det til disk fordi det tar 3-4 minutter å pumpe data inn i databasen. Greit å slippe det hver gang du starter REPL-et.

Det er nesten like lett å ha ting på disk, du må bare laste ned transactoren en gang 🙂

Nice, skjønner! Ja, det blir jo mye mer REPL-vennlig å kunne gjøre spørringer med én gang enn å først måtte kverne data i flere minutter.

Det kommer an på mengden. in-memory er helt fint til det ikke er det 😄

@teodorlu her er nedlasting og start av transactor: https://github.com/Mattilsynet/matvaretabellen-deux/blob/main/Makefile#L11

Bare endre ../../datomic-data til der du vil at Datomic skal lagre på disk, og så er du good to go

ultradigg at dette er open source ❤️

Staten ❤️

sånn statlig finansiert utvikling og forskning bør gjøres!

TIL: “deux” betyr “to” på mellomfransk. Ikke fransk, ikke gammelfransk, mellomfransk.

datomic-config direkte i en makefile var en veldig god idé_!_ Tidligere har jeg bare puttet Datomic et sted, som jeg synes har vært litt … lite oversiktelig.

Jeg trodde det var fransk, så lite kan jeg om det språket 😄

korreksjon: ser ut som det funker på fransk også! Bakoverkomtatibelt, sånt liker vi.

Ja, jeg har også hatt Datomic slengende tidligere. Fint at alt som kreves for å jobbe med prosjektet er fullt spesifisert av configen i prosjektet.

ja, jeg liker det veldig godt jeg også. Ikke “også må du sette disse 1546 miljøvariablene i intellij og starte databasen før du trykker på “start”-knappen”

Det er ingen intellij-hjelp for prosjektene våre 😂

Men ja, enig

setter dere miljøvariabler når dere jobber lokalt? Eller sørger dere for at variabler har defaults (i appen) som funker i lokal utvikling? (edit: dette kan jeg sikkert lese meg til, dere har jo koden åpent)

Vi bruker ikke miljøvariabler til noenting akkurat nå. Har ikke pleid å gjøre meg avhengig av det.

config-opplegget vårt er behørig beskrevet i confair-README 😅

hehe, riktig 😄

kort fortalt: Alt skal funke ut av boksen lokalt

Launchpad hadde en ganske kul greie for env-variabler

https://github.com/magnars/confair

Men confair er "the way"

Litt lengre forklart: • alt av dev-config sjekket inn og delt • mulighet til å overstyre lokalt, i en fil som ikke sjekkes inn • prod-config og dev-config er 100% adskilt - ingen gjenbruk

sunt. Så ting krasjer med et smell hvis noen (ved et uhell) prøver å kjøre appen i prod uten å sette noe config?

nettopp det

env-variabler brukes kun til å fore inn ting som må komme runtime i prod. Vi har brukt det til git sha og hemmeligheten som dekrypterer configen

liker illustrasjonsbildet i confair 🙂

😂

Forøvrig, kult protip: Vi har tidligere transacta git-shaen på koden til Datomic ved oppstart i prod. Da kan du lett se hvilken versjon av koden som har opprettet ethvert stykke data i databasen.

Alternativt kan man annotere selve transaksjonen med git-shaen, da får du en enda mer direkte kobling.

Apropos ingenting.

det er litt utsatt for timing-issues når man kjører flere app-prosesser, men vil gi et inntrykk i hvert fall. Løsningen på det har Christian allerede skrevet ut. 😅

jeg har med meg git-sha i prod på en app jeg har jobbet på selv, supernyttig å kunne se når nye versjoner har startet opp. Per nå er denne fra en miljøvariabel fordi det er noe plattformen tilbyr.

$ curl 
{:git/sha "a00b84b815c214ecb2b586732c0c824c3035e722",
 :last-modified-file-time "2024-03-05T10:55:42Z",
 :access-logs-size "46 MB",
 :hits 508796}

"mikrobloggeriet" 👌 👌

Navnet ble funnet av https://www.linkedin.com/in/hmkristiansen/, en tidligere kollega. Fram til det tidspunktet het initiativet OLORM (“Oddmund, Lars og Richard sin Mikroblogg”). Det navnet kan jeg love deg at folk ikke likte 😄

(hvis dere skulle finne på å lese koden (ikke gjør det da 😅) vil dere sikkert observere at vi gjør litt manuell jobb for å holde styr på ting folk har publisert og grupper for å publisere ting. Det hadde blitt enklere med feks en database som Datomic. Siden hadde også blitt kjappere med flate filer. Men da kunne vi ikke brukt Mikrobloggeriet som treningsarena for utviklere som vil prøve Clojure. Og vi kunne heller ikke flagget features på måten vi gjør det nå. Mye som kan forbedres for det trente øyet.)

Slapp av, det meste jeg gjør kunne også vært gjort bedre 😊

næh, det nekter jeg å tro på! 😁 </sarcasm>

Hvis all koden er perfekt, så er den enten veldig liten, eller du har gjort feil trade-off en eller annen plass. 😅

egentlig veldig kult hvordan tree-seq går akkurat dette veien. Hvis du gir meg (A) en trestruktur, (B) en måte å avgjøre om det jeg gir deg er en node eller et blad og (C) en måte å avgjøre alle trær, så kan jeg gi deg en måte å traversere over tingen din. Hvis du skriver (B) og (C) som funksjoner, kan du bruke dem selv, eller bruke dem i tree-seq.

funksjonskonposisjon, eller som noen ville sagt, funksjonell programmering

async/await er vel bare syntaks-sukker for promises?

Jepp. Og der jeg aldri har jobbet med promises, fordi jeg slutta med JS før de kom, synes jeg at async/await prøver å gjøre noe som er vanskelig enkelt, men leverer en gjeng med foot guns istedet.

callback hell er på en måte bra, for det det er så opp i trynet ditt åpenbart at du gjør ting feil.

const foo = async (whatever) => return await fetch(...); Dette blir da:

const foo = async (whatever) => return new Promise((resolve, reject) => {
  fetch().then(resolve, reject);
});

Jeg drister meg til å påstå at denne forvirringen først og fremst handler om at du ikke er like kjent med promises som callbacks og core.async

Behøver ikke driste deg til å påstå det. Jeg vil påstå at det er helt korrekt!

Eksempelet over er da basically det samme som:

const foo = async (whatever) => fetch(...);

Jo, men! Jeg vil fange exceptions som fetch kaster i foo som i eksemplet lenger ned.

Så jeg må resolve promiset som fetch returnerer for å få fanget exceptionen i den blokka?

Skavvisjå

Sånn ca https://dev.to/dionarodrigues/fetch-api-do-you-really-know-how-to-handle-errors-2gj0

Dette eksempelet fungerer nok ikke som ønsket:

const foo = async (whatever) => {
  try {
    return fetch(...)
  } catch (e) {
    will this code ever be executed
  }
}

Korrekt

Mens dette:

const foo = async (whatever) => {
  try {
    return await fetch(...)
  } catch (e) {
    will this code ever be executed
  }
}

const foo = async (whatever) => {
  return new Promise((resolve, reject) => {
    try {
      fetch(...).then(resolve).catch(reject);
    } catch (e) {
      // sync exceptions
      return Promise.reject(e);
    }
  });
}

(Jeg er ikke ekspert på async/await syntaks, men jeg har brunt belte i promises)

Jeg har sånn omtrent akkurat kjøpt meg promise-drakt, ha’kke fått belte ennå.

😄

Anbefaler et lite dedikert dypdykk i promises uten syntaks

Men jeg tror jeg hadde kanskje gult belte i callbacks for ti år siden.

Jeg er usikker på om jeg syns syntaksen i async/await er en nett positiv

Den piggie backer eksisterende syntaks med ny semantikk

Det er vel det som er observasjonen min. Det tar noe som krever at du har tunga rett i munnen, men som funker og får det til å se ut som noe som du ikke behøver å tenke så mye på. Hvilket er feil.

Forskjellen på den await ’en etter return har masse å si, men det er ingen ting som indikerer det. Typene forblir de samme, og verken kompilatoren eller linteren gir deg noe hint om at du ikke gjør det du tror du gjør.

Tror egentlig at det er ålreit, men try/catch blir plutselig ugrei

Jøss, sier du at typesystemet ikke garanterer ar programmet ditt virker?

Man kunne også kanskje argumentere for at api’et til fetch er dust, i og med at det blander sammen promises og exceptions.

Wow. Har fetch synkrone exceptions også?

Såvidt jeg kan forstå, så ja.

Hvis du får en nettverks- eller corsfeil, så kaster den en exception, pr blog over her i tråden.

Lul. Det er klassisk w3c, de er ikke så gode på API-design

🙂

Jeg tror forøvrig at jeg hadde forventet at

const foo = async (whatever) => fetch(...);

Nei, det er hele magien med Promises

Det er alltid Promise<Response|Error>

(jeg har ikke typesignatur-belte, så tilgi syntaks)

Så promises kollapser lissom?

Jepp

Ellers hadde det blitt umulig å jobbe med

then er som <! 😄

Altså, det er forsåvidt mulig å kalle resolve med et promise, da må du gjøre then to ganger. Men det er omtrent like fornufig som å legge en kanal på en kanal med (<! chan other-chan)

Fikk anbefalt denne https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/ > I just jammed a bunch of fancy PL language in that paragraph so it probably sounds like a sweet deal, but it’s basically snake oil. Kommer noen morsomme quotes litt nedi der.

Jeg tror du ville ha godt av å skrive denne koden med Promise-API-et (uten syntaks) frem til det sitter

Eller til og med callbacks. Men ja. jeg tror det hadde vært gunstig.

async/await er kun syntaks, det er promises som er mekanismen. Dette blir lettere med en god forståelse av promises.

Jeg er heldig, for jeg lærte meg promises før det fantes syntaks for dem 😄

> Wanna know one that doesn’t? Java. I know right? How often do you get to say, “Yeah, Java is the one that really does this right.“? But there you go. In their defense, they are actively trying to correct this oversight by moving to futures and async IO. It’s like a race to the bottom.

tipper det er svært få som bruker promises lenger, så det som blir nevnt her er fort gjort å ikke få med seg 😓

Du mener at sensei @christian767 er utdatert og sitter i hagen sin og roper på skyene?

De bruker det, men er ikke klar over det

Jeg er utdatert som faen

Men jeg skjønner ihvertfall hva som skjer

Hvis du skriver om koden fra async/await til eksplisitte promises så får du lov å uttrykke deg med callbacks @U04V5VAUN 😄

Hvis bare fetch hadde hatt callbacks 😕

fetch().then(function (res) { voila! });

const foo = (whatever, onError, onSuccess, onFetchThrows) => { try { fetch(...).then(onSucces).error(onError) } catch (e) {  onFetchThrows(e)}}

Hver gang du kommer med en sånn oneliner må jeg copy-paste den til emacs og formattere den for å klare å lese den 😅

Du er gammel

hehe

Jeg mente ikke nødvendigvis at du skulle gå så all-in på callbacks, men at new Promise(function (resolve, reject) { ... }) er litt mer callback-orientert enn await

Blir det bedre for deg hvis jeg skriver:

function foo(whatever, onError, onSuccess, onFetchThrows) {
....
}

Ja takk

Jeg har mest problem med try/catch på én linje

Ja, det er helt håpløst.

Det ville jeg ikke gjort i Clojure engang

Det er artig å lese kommentarene i den blogposten jeg lenket til. Blogposten ender med a si at threads er en enklere programmeringsmodell (noe jeg vel er veldig enig i). Kommentarfeltet blir da fullt av “Jammen threads skalerer jo ikke. Kanke ha millllioner av threads lissom”. Og da ler jeg litt.

hehe

Da mener du at en funksjon som kaster exception ikke er ren?

Lazy exceptions er den aller største kilden til frustrasjon i Clojure tror jeg. Det er ikke ofte jeg er utfor det, men det er veldig ubehagelig når det skjer 😁 😅

> Da mener du at en funksjon som kaster exception ikke er ren? Hmm. Ja, det var antagelsen. Hva tenker du? Kan en ren funksjon kaste exceptions?

> Lazy exceptions er den aller største kilden til frustrasjon i Clojure tror jeg. Det er ikke ofte jeg er utfor det, men det er veldig ubehagelig når det skjer 😁 😅 Jeg tenkte over det da du kom med et pmap-eksempel som gjorde HTTP-spørringer her om dagen (tror jeg).

user=> (doc pmap)
-------------------------
clojure.core/pmap
([f coll] [f coll & colls])
  Like map, except f is applied in parallel. Semi-lazy in that the
  parallel computation stays ahead of the consumption, but doesn't
  realize the entire result unless required. Only useful for
  computationally intensive functions where the time of f dominates
  the coordination overhead.

kanskje du kan lage en “hook” som brukere kan bruke som de vil, og gjøre eventuelle kall til tap> selv?

Ja, det blir nok det

Jeg liker egentlig litt at det ikke er fullt av vilkårlige ting på data som sendes til tap>. Men jeg har ikke brukt tap> kjempemye selv. Clerk har en tap>-viewer: https://book.clerk.vision/#tap-inspector Som jeg brukte til å logge noe data basert på HTTP-spørringer. Den tap-vieweren baserer seg på tilstand i et atom. Så har de en funksjon for å “tømme” det atom-et.

Helt enig. Men jeg har heller ikke brukt tap så mye som jeg sikkert burde, så var litt usikker på hva som var gjengs. Men jeg er nå helt overbevist om at applikasjonsutvikleren bør ha full kontroll over hva som går på tap.

Det høres jo uansett ut som et trygt valg for meg. har du lest dette skikkelig kule blogginnlegget fra 2021? https://www.kodemaker.no/blogg/2021-11-mer-mindre/

😁

😂

Idéen var jo å fjerne den konkrete loggingen fra featuren

Altså fra "den logger interessante warnings og feil" til "den kommuniserer ut warnings, og har en valgfri default logger for dem"

Jeg har lyst, da dette så utsøkt ut!