Her har jeg et veldig konkret eksempel å vise 😅 https://github.com/kodemaker/kodemaker.no/blob/master/resources/db-schema.edn#L474-L482

:person/favorites-at-the-moment var kjempelurt!

Jeg vil på det sterkeste anbefale namespaced keys til skjemaet ditt. De skal ligge i en global katalog og bør være kvalifiserte.

> Eller bør man heller modellere at en person har gitt utrykk for at personen liker noe på et punkt i tid, så det blir som en “observasjon”? Dette er jo akkurat datamodellen i Datomic. Du trenger ikke gjøre noe spesielt for å få til denne.

Ser for meg at det kan være spennende å se på dette over tid. Lage preferanse-over-tid diagram ala wikipedia bandmedlemmer-over-tid.

Bare et query unna 😄

Ja, da kan du bare holde styr på "favoritter nå" som du tenker, og når du vil lage denne grafen kan du be om historikk på attributtet og få alle endringer gjennom tidene.

Ingen spesiell modellering som skal til.

Sant! Dette svaret var mye enklere enn jeg hadde forventet. Tusen takk! Kjempekult at jeg bare kan se hva dere har gjort på skjemaet direkte. Open source 😸 😍

En ting som ble nevnt litt sånn i forbifarten på meetup’en, men som jeg tror er ille viktig er følgende: Hvis du trenger å ta hensyn til tid, modeller inn domenetid og ikke stol utelukkende på tx tid.

Godt poeng. Vi vil for eksempel ikke kunne “fikse feil i fortiden” hvis vi bare modellerer “liker akkurat nå” med datomic. “per skrev at han likte “mester” i 2003, men han mente å si at han likte “tester”"

Jo, men jeg tror det er mer sånn som f.eks i et CMS der man vil at en artikkel skal publiseres på en gitt dato, eller no. Da må man modellere inn domenetid, men det er sånn man kanskje glemmer å tenke på fordi man tenker at Datomic har tid innebygget.

Og, f.eks hvis man skal lagre en person, så holder det ikke å si at vedkommende er født på det øyeblikket personen ble transacta inn i datomic.

Jeg tror jeg ville voktet meg for å modellere tid med motivasjonen du kommer med over @U3X7174KS. Da kommer du fort til å manuelt modellere tid på alt. Dessuten er det interessant nok at det sto “mester” der i 2003 - for det var det det gjorde.

“Har denne tingen et livsløp utenfor databasen min?” er en ålreit lakmustest

Ja, man må modellere domenetid selv, men du skal heller ikke kimse av alt du kan bruke datomics tid til 🙂

Ja, den største risikoen for meg personlig akkurat nå er nok at jeg tenker alt for komplisert og roter meg bort i alle eventualitenene.

Fort gjort når ting er nytt 🙂

Uten at Datomic nødvendigvis er svaret på alle livets spørsmål!

Modeller ting som du ville gjort i en sql-database, så kommer du langt

Så kjedelig da 🙂

Kjempekjedelig. Du får heller ikke bruk for spennende makro-baserte biblioteker for å snakke med databasen. Dølle greier.

Modelleringen er som oftest helt rett fram. Det er leverage du får over dataene dine etterpå som er spennende.

Så du denne i Deref i april? https://favila.github.io/2023-04-18/datomic-choosing-ref-direction/ Tenker også at “rett fram” ofte er greit, særlig for components (og akkurat slik du har brukt favorites-at-the-moment og want-to-learn-more). Favila gjør likevel en case for at bakfrem i noen tilfeller bør vurderes. Kanskje ikke en viktig problemstilling for “norske” data. Hans passenger er en frittstående entitet og ikke en komponent, kunne likevel ønske han hadde nevnt isComponent i samme slengen.

Ikke sett. Takk!

Helt enig, men med en bitteliten modifikasjon. Rene funksjoner skal ikke logge. Det medfører at biblioteker med urene funksjoner burde kunne få lov til å logge

Men, mener å huske at dette var en av innsigelsene mine til @UGJE0MM0W sitt et eller annet bibliotek som jeg hadde glemt at jeg hadde innsigelser til? mot?

Når biblioteker logger må de velge et eller annet verktøy for å logge. Det påfører meg potensielt avhengigheter og behov for konfigurasjon. Nei, full stopp.

For prosesser der det kan være interessant å få granulær informasjon er det bedre om man tilbyr en mekanisme for å logge selv. Feks en kanal som emitter logg-data, tap e.l.

Enig. Men synes godt de kan støtte å ta inn en optional logg-funksjon som parameter.

Ja, det er en pragmatisk løsning.

Jeg har gjort det siste i Proletarian. Du kan sende inn en funksjon som blir kalt når det skjer noe. Default-implementasjon: skriv til STDOUT (`println`). Men jeg ligget våken mang en natt og tenkt på dette. Jeg ser at noen bibliotek bruker clojure.tools.logging , som i seg selv ikke logger, men er en “fasade”, altså at den trenger en implementasjon. Da binder du ikke (som biblioteksforfatter) konsumenten av biblioteket ditt til en bestemt loggimplementasjon. Men du binder deg likevel til noe mer spesielt enn bare en funksjon.

Absolutt. Funksjon er mer direkte, som i min bok nesten utelukkende er positivt.

En ulempe, potensielt, er at funksjonen kalles for alle loggmeldinger, mens typiske logg-makroer sørger for at ingenting kalles hvis loggnivået er satt til å ikke logge den aktuelle meldingen. Det blir altså mer jobb, noe som går ut over ytelse. Men da skal du være i en veldig tight loop, og ellers ikke drive med noe IO, hvis det er loggingen som blir flaskehalsen. Jeg har konkludert med at dette ikke er en ikke-sak i Proletarian (som driver med mye IO, nødvendigvis).

Godt poeng. Jeg tenker at det i all hovedsak er prosesser som driver med IO som har glede av å tilby noen form for logging. Mer computational greier bør kunne brytes ned sånn at man kan pusle sammen byggeklossene selv, og strø inn logging selv om nødvendig.

I Proletarian sitt tilfelle (som er en prosess, skulle man kunne si) er det jo fint å kunne se i loggene at jobbene kjører (og evt at det gikk til h*lvete).

Ja, så den må tilby en mekanisme for det. Jeg vil bare ikke ha noe av at den velger loggeverktøy for meg. Og det gjør den heldigvis ikke 🙂

Vi har jo noe slike hos oss:

(defn- do-work-fn [ardoq-ds job]
  (fn []
    (log/with-tracing!
      {:job-id (core/id job)
       :job-name (:name job)}
      (metrics-service/with-utilization-metric
        metrics-service/registry ::metrics-service/thread-utilization
        {:thread-name (util/current-thread-name)
         :org (get-in job [:searchable-data :org-id])
         :task (str "execute-" (name(:name job)))}
        (log/debugf "Running job: %s" (job->safe-to-log-details job))
        (util/with-suppressed-errors-ignoring-interruption-caused
          (trace-service/with-transaction! "job" (name (:name job))
            (run-job! (get-system) job)))
        (job-done! ardoq-ds job)
        (log/debugf "Finished running job: %s" (job->safe-to-log-details job))))))

Min logger-funksjon, som jeg sender inn til Proletarian, ser slik ut:

(defn logger
  [x data]
  (case x
    ::worker/polling-for-jobs
    (log/trace x data)

    (::worker/handle-job-exception ::worker/handle-job-exception-with-interrupt)
    nil                                                     ;; Already logged in handle-job-wrapper!

    (::worker/sql-transient-exception ::worker/job-worker-error)
    (log/error x (dissoc data :throwable) (:throwable data))

    (log/info x data)))

Dette er den funksjonen som vi submitter til et thread-pool for å kjøre jobben. Dersom vi hadde brukt proletarian, skulle man kunne sett for seg at det var mulig at vi skrev denne funksjonen som vi så ga til proletarian, men at proletarian hadde en default-kjør-jobbene-funksjon som kunne brukes.

Proletarian tar en dedikert logge-funksjon

Du kan selvfølgelig gjøre som du viser over også, når du kjører jobbene dine. Men den vil kun gi deg informasjon om jobben din, ikke om arbeidet til Proletarian for å orkestrere jobbene.

Så basically, proletarian kunne tilbudt:

(defn run-the-thing
  ([] (run-the-thing* our-own-runner))
  ([your-runner] (run-the-thing* your-runner)))

Proletarian lar deg gi en worker en loggefunksjon, og så har den en handle-job! multi-metode, som du kan gjøre hva du vil i.

Jepp, det er vel akkurat det jeg er ute etter.

stryk det siste, multimetoden er vår 😂

(worker/create-queue-worker
 db
 (fn [job-type payload] (jobs/handle-job! job-type payload (assoc system :now (Instant/now))))
 {:proletarian/queue :chill-jobs
  :proletarian/polling-interval-ms 5000
  :proletarian/worker-threads 1
  :proletarian/log logger})

Sånn oppretter vi en av workerne våre

Riktig, bortsett fra at handle-job! nå er en funksjon du sender inn (som i sin tur kan være en multimetode, men det er opp til deg).

Ja, jeg var litt rask 🙂

(Min bane her i livet)

generelt er jo logging i logikk en tidvis code smell. Functional core, imperative shell, returner data om hvordan det gikk i stedet for å skrive tekst til en logg 🙂

Huh, godt poeng! "når du bare har funksjoner og data og mapping til funksjonen er tydelig, trenger du ikke grave i hvordan det er gjort" Nå satte du ord på noe jeg ikke har klart å formulere!!!

Særlig når funksjonene mapper fra data til data, og "noe har gått uventet" bare er data.

Absolutt. Så de bibliotekene jeg tenker på er de som har prosesser, hvor det kan være interessant å få informasjon underveis, ikke bare sammen med svaret

Ja, sant. Når du har prosesser (eller tilstandsmaskiner eller asynk-ting), går det jo ikke an å bare returnere data.

Nei, men du kan fortsatt ta imot en funksjon, eller returnere en kanal som kommuniserer underveis.

når kommer patterns-boka, Christian? 😄

haha

“fyr med avvikende meninger om software skriver bok om hvorfor hans idéer er bedre enn alle andres”

konsensus er jo et datapunkt i retning av “fravær av tenking” 😄

😁

høres ut som en vel så bra pitch som “fyr som har brukt Kotlin på backend i under ett år når han egentlig gjorde mest app skriver bok om hvorfor Java-folk bør bruke Kotlin til å skrive kode som er mest mulig lik Clojure”

hehe

Har du noe innsikt i hvordan det har gått med boka så langt?

absolutt ingenting. Spurte i slutten av mars, da fikk jeg høre at jeg skulle få kvartalsrapporter, har enda ikke hørt noe 🤷

de store forlagene er ganske akterutseilte

har også sett null innsats fra forlaget på markedsføring

høres kjent ut

virker som prosessen dems er “gi ut N Kotlin-bøker, håp at én gjør det bra av seg selv”

det er det nok

min erfaring var helt den samme: fikk veldig god oppfølging under produksjon av boka (masse folk involvert), og når den var ferdig så var den ferdig

for å besytte meg selv fra meg selv har jeg passet litt på at boka ikke er hjertebarnet mitt, så konsekvensen er vel at boka er ingen sitt hjertebarn

haha jepp, radiostillhet etter publisering her og ja

opplevelsen av å gi ut et album på en stor-ish label var forøvrig helt lik

haha, såpass ja

forlaget slår meg mest som en gruppe investorer som tilfeldigvis valgte å fokusere på tech-bøker

mulig jeg falt litt mellom to stoler dog, sjefsredaktøren for boka bytta jobb underveis (til Manning, så håper å slenge meg på det toget om det blir flere bøker i fremtiden)

brb, macos har nå sin ~månedlige “klarer ikke å starte noen nye prosesser og må restarte”

jøss, aldri opplevd

tror simulasjonen har en feature hvor de som liker Windows litt opplever flere problemer med macOS enn de som foretrekker macOS

😄

Det er også verdt å vite om https://github.com/redplanetlabs/specter

Har du en lignende setning som forklarer zip? 😄

Nei, for den har jeg ikke brukt 😄

Jeg lurte på akkurat det du lurte på før jeg skrev artikkelen, @leif.eric.fredheim. "walk". Den høres lur ut å kunne. Siden den følger med clojure og til og med har sitt eget namespace. Videre har jeg lyst til å lære meg Zip! Men jeg har ikke funnet noe godt problem ennå; vil gjerne ha noe jeg kan gjøre med zippers først. Da synes jeg det er lettere å lære.

Jeg kom til skade for å foreslå å samle alt i ett monorepo. Det var for tidlig for enkelte 😅

Hvilke ting? Hva er de gode grunnene? 😄

f.eks at databasen bare modellerer databasetid, ikke domenetid. Å modellere domenetid som XTDB gjør vil kreve uante ting av indekseringsprosessen

Ålreit. 👌

mulig det er good shit, men har ikke klart å oppdrive gode forklaringer på disse tingene

XTDB mangler kanskje en Rich Hickey som kan krystallklart presentere valgene som er tatt 🙂

Ja, det at Datomic kun har databasetid og ikke domenetid er en ulempe med Datomic, syns jeg. Som jeg nevnte i en annen tråd her, har jeg ikke fått prøvd XTDB2 med valid-from og valid-to ennå, så jeg er foreløpig usikker på om det er riktig av Datomic å overlate dette 100% til applikasjonen eller ikke.. Vi får vel med SQL:2011 før eller siden både databasetid og domenetid i PG også. Hvis domenetid gir out-of-the-box for publisering frem i tid eller priser som skal av og på og sånn, så kan det være ganske nice - dog litt usikker på om det trigges events når ting går inn/ut av validity. Hvis ikke, er det fortsatt litt som må gjøres i domenet;)

Krystallklart vet jeg ikke, men de har skrevet litt om records vs facts og sånn. https://docs.xtdb.com/concepts/trucks-tubes-truth/ https://docs.xtdb.com/concepts/strength-of-the-record/ Uansett interessant med ulike perspektiver!

tror du er inne på det der, ja. Databasetid er gitt, og kan styres av databasen, men en generisk løsning på domenetid på databasenivå (aka databasen forsøker på å out of the box modellere domener?) blir en helt annen sak

> Cabin life it isn’t for everyone. The anxieties caused by mortgage, insurance, water, heat, and electricity bills are replaced by unconventional stress PET PEEVE TRIGGERED, morro dokumentasjon får meg til å falle av kjapt

det demrer hvorfor jeg ikke helt grokker XTDB 😄

Helt annen sak, enig. Dog, valid-from og valid-to så man også kan kjøre as-of på fremtidige datoer virker ganske universelt for ganske mange domener. Om det er et abonnement eller ladeavtale eller hva, som man ønsker å modellere. Skjønner godt at Datomic har gjort det enkelt/universelt for seg selv ved å droppe å tenke på det, men samtidig ser vi jo da at det fortsatt er temmelig mye spørsmål rundt dette og mange som ikke grokker Datomic. Det er i grunn litt uforståelig her også, bare at den har du jobbet med lenge;)

Tror Juxt har jobbet mye innen finans. Der kommer kanskje domenetiden fra et annet system. Så da kan de få fine, temporære spørringer selv på data som de ikke lager selv.

> PET PEEVE TRIGGERED, morro dokumentasjon får meg til å falle av kjapt I går likte du ikke beskrivelser av musikk - hva ER det du liker egentlig? 🙂

snakket akkurat med noen om “svisker” og - altså klassisk musikk som folk flest liker, men som ikke er bra nok for oss kjennere

er helt åpen for at XTDB har amazing trade-offs jeg ikke forstår, det er jo virkelig ikke en “open source Datomic” og jeg har ikke grokka den

For skjemaløst er "meningsløst"?

😂

Hva tenker du på da?

generelt tror jeg mange i Clojure-land er averse til å binde seg til en dependency som forlater deg som er på 1.x og går over på 2.x

Å ja, skjønner.

Joa, men du vil vel uansett være produktiv og ikke måtte vente i 2 uker på å få maskinen din for så å vente 3 uker på å få tilgang til github og så bruke den neste måneden på å få PR’en din ut i prod?

Da er det vel kulere å ha maskina fra dag en, oppe å gå før lunch og første (trivielle) bit kode ute i produksjon før du går hjem første dag?

Jo!

Men flinke folk er skumle. De vet liksom så mye.

Helt enig. Alle de nyansatte er skumle 😉

Kjenner meg igjen! 😁 På prosjektet jeg jobber på nå er vi to (utvikler/produktperson). Vi har fått litt designhjelp tidligere. Men det vi lager når vi skal få ut noe nå ser ikke like bra ut ... Så kommer en designer inn. Flikker litt på avstander, fonter og farger. Plutselig ser det megaproft ut, og designeren har bare brukt noen timer.