Clojurians Log v2

Kan ikke bidra til Emacs-biten, men liker at gray xx soft er hvit 😄

haha, ja jeg reagerte akkurat på den selv 😄

tror tanken min var at den var helt utblåst i xx-soft, der den vil få maks kontrast mot en saturert farge.

Den burde egentlig ikke hete gray i det hele tatt, sikkert bare fg (foreground)

lsp-mode sin css-pakke legger til fargen som en liten firkant etter hash'en.

takker! da skal jeg se om jeg klarer å grave ut den koden fra lsp-mode 🙂

Fargene kommer faktisk fra lsp-serveren. eglot (som jeg bruker) ser ikke ut til å bruke dette, dessverre.

litt nysgjerrig på om du sitter i Clojure-kodebase nå eller noe annet sted? Jeg kunne kommet på den kommentaren der enten hvis jeg satt i en fin FKIS-kodebase, eller hvis jeg kjente problemer som kunne vært unngått …

sitter på en fin FKIS-kodebase i Kotlin 🙂

Spennende! Det er ganske blankt for meg hvordan både hvordan man da gjør kommandoer/effekter på en hyggelig måte, og hvordan du jobber med immutable data. Bare dataklasser og SQL? Tror ikke du dekket FKIS i boka di? Jeg leste ikke hele, men blant det jeg leste var det i alle fall ikke nevnt FKIS.

nei, hadde ikke rom for og gå såpass i dybden, det endte vel opp som en slags newbie-bok og ikke et dypdykk

greit å faktisk bli ferdig med boka 😄

kjernen i FKIS er vel at man har to "bolker" med kode: en bolk som kjører businesslogikk og finner ut hva som skal skje, og en del som utfører jobben. Første bolk får lov til å gjøre SQL-er

bare selects selvfølgelig, ikke noe skriving

Ikke gjort noe spesielt på effekter / kommandoer? Når ting skal gjøres så bare kjører skallet imperativ kode?

> Første bolk får lov til å gjøre SQL-er Det var en pragmatisk og fin tilnærming!

Hos oss har vi jobbet en del med å ha høynivå kommandoer som kan "utvides" til effekter med en ren funksjon. Så er effektuering av effekt imperativ / uren.

hensikten er at det som er vanskelig (aka businesslogikk) skal kunne kjøre isolert og ikke være avhengig av maskineri! Så vi har masse kode av typen "hent ut det som skal sendes til regnapssystemet gitt at dette varemottaket nettopp ble lagret". Det er der sikkert 95% av den vanskelige koden ligger. Det å sørge for at den kalles når det skjer noe med et varemottak, og det å sende outputen av funksjonen til regnskapssysatemet, er helt generisk og "dum" kode

og sånn systemet vårt er rigga går det ikke an å isolere businesslogikk fra SQL

har ikke så alt for mye opplegg eller struktur rundt dette, er mere "sånn skriver vi kode", og så er det ganske åpenbart fra konteksten om du er i kø-event-maskineriet eller I/O-maskineriet eller businesslogikk-koden

Utfordringen er tester, dvs at de blir trege. Eller bruker dere kanskje en inmemory-database?

nei, har bare akseptert at vi må leve med det. Kjører en del av testene i parallell, men suiten tar vel en 1.5 ish minutter (på min ultra-raske desktop-maskin)

Det er egentlig litt overraskende at det ikke finnes en inmemory-variant av postgres. Jeg tipper at ganske mange savner det 🙂

Lurt! Det skal jeg teste :)