Fork me on GitHub
#clojure-norway
<
2024-05-28
>
cjohansen06:05:11

Etter mye mas om hva NATS er og hvordan det funker har jeg omsider skrevet et innlegg om hva vi bruker det til (ihvertfall én av bruksområdene våre): https://parenteser.mattilsynet.io/nats-import-eksport/

💯 4
👍 4
🙏 2
teodorlu07:05:40

> Den viktigste delen av denne konfigurasjonen er: >

:nats.stream/retention-policy :nats.retention-policy/work-queue
Nysgjerrig på hvorfor :nats.stream/retention-policy og :nats.retention-policy/work-queue er i forskjellige navnerom? Er det så enkelt som at dere sier dere fornøyd med to “nivåer” i hierarkiet av navnerom, og ikke ønsker å innføre et tredje (`nats.stream.retention-policy`)?

teodorlu07:05:49

Hvis jeg skal prøve å gjette selv, tenker jeg at dere prøver å etablere et navnerom. Da er nats.stream én ting, nats.consumer én ting, også videre.

cjohansen07:05:13

Godt spørsmål. Disse tingene er foreløpig ikke satt i stein. Men ja, du har ressonert deg frem til grunnen. Ønsker ikke uendelig lange namespaces, vil at alt skal ha "nats" i seg, og setter av ett nivå i namespacet til funksjonsområde.

👍 1
cjohansen07:05:48

nats.stream/retention-policy er config for en stream

👍 1
cjohansen07:05:33

nats.retention-policy/work-queue er en type retention policy.

cjohansen07:05:52

Ikke verdens tyngste argument kanskje, men gir mening for meg 😅

👍 1
cjohansen07:05:26

Jeg tenker det er en ålreit tradeoff mellom praktisk i bruk og tydelig hva det er

👍 1
teodorlu07:05:22

Ja, jeg kjøper den. Føler man kan argumentere for at å unngå navnerommet nats.stream.retention-policy reduserer koblingen mellom “stream” og “retention policy”. Da åpner man for at andre ting enn stream kan ha en retention policy. Litt ala hva dere argumenterte for da dere modllerte kommuner i Datomic? Det var noe med alt alle ting kunne ha URL-er i databasen. Det høres i alle fall litt analogt ut i mitt hode.

cjohansen07:05:31

Ja, veldig godt poeng!

teodorlu07:05:44

Flott tekst! Spennnende å lese. Både med datamodellering (navnerom, attributter, data) og dataflyt (løs kobling mellom kildesystem og målsystem). Spennende start på morgenen!

❤️ 1
cjohansen07:05:55

Absolutt relatert. Dette merker jeg at jeg nok tar litt for gitt. Som du påpeker så ville det å putte "stream" inn i navnerommet gjøre den unødvendig spesifikk

👍 1
anders08:05:59

Fin bloggpost @U9MKYDN4Q 👍 Ettersom ack'ede meldinger vil forsvinne fra køen har man ikke innsikt i hvilke meldinger som har vært behandlet. Er det noen snedig måte i NATS håndtere dette på, eksempelvis flytte ack'ede meldinger over i en egen strøm?

cjohansen08:05:14

Dette er oppførselen på work queue. Dersom du ikke ønsker at meldingene skal bli borte så kan du bruke en annen retention policy, feks "limits" som er default. Da kan du sørge for at meldinger aldri forsvinner.

cjohansen08:05:30

Consumeren vil da vite "hvor den er", altså hvilke meldinger som er behandlet og ikke.

cjohansen08:05:02

Men akkurat for importen jeg beskriver her, så konverterer vi en import til en command, som er en ny melding på en ny kø. Denne køen er mer persistent, derfor trenger vi ikke persistens på import-køen.

cjohansen08:05:04

Om det gir mening.

anders08:05:24

Skjønner 👍

jonas09:05:33

Skriver stort sett bare clojure solo men i jobbsammenheng på prosjekter med mer enn tre utviklere (java/kotlin) og relativt store og hyppige endringer, e.g produktutvikling, foretrekker jeg noe ala hexagonal architecture. Dere som har jobbet på clojure prosjekter med litt flere utviklere, hvordan organiserer dere koden? Ser for meg at en tilsvarene organisering er lettere å få til i clojure da grensesnittene blir mer implisitte og kanskje det blir litt mindre sermoni? Gjerne linker til blogposter o.l

cjohansen10:05:32

Litt på siden av hva du spør om, men vi jobber også med produktutvikling, men etterstreber å strukturere koden slik at vi ikke har "relativt store og hyppige endringer". Tilrettelegger heller for å legge til kode for nye features, uten å røre det som funker i særlig grad.

cjohansen10:05:00

Disclaimer: jeg aner ikke hva hexagonal arkitektur er, så mulig det svarer ut noe av det samme 🤷

jonas11:05:42

@U9MKYDN4Q jepp blir litt av det samme hexagonal legger opp til

pez11:05:43

Jag jobbar på samma företag som @U1G0HH87L , arkitekten bakom Polylith. Just nu är han i ett Java-projekt och något han svär högt över är just all ceremoni.

tengstrand11:05:49

Polylith består av mycket mindre och frikopplade "Legobitar" som går att dela mellan projekt + att man får en "single development experience". Inget av det återfinns i P&A.

oddsor14:05:25

I dag ble det (re)postet en strålende idé til sortering av tall på jobb-slacken: Spinn opp tråder som sleeper tilsvarende størrelsen på tallet og print tallet. Jeg syns det var litt dårlig å printe tallet, så jeg prøvde en variant som putter tallene på en kø i stedet. Må si det ble mye bedre 👍 Tar 10 sekunder å sortere 1000 tall da, men her kan man tune ned presisjon for bedre ytelse ved å redusere varigheten på sleep’en.

(ns bad-sorting
  (:require [manifold.stream :as stream]
            [manifold.deferred :as d])
  (:import [java.util.concurrent Executors]))

(let [stream (stream/stream)]
  (doseq [n (shuffle (range 50))]
    (d/future-with (Executors/newVirtualThreadPerTaskExecutor)
                   (Thread/sleep (* n 10))
                   (stream/put! stream n)))
  (stream/stream->seq stream 50))
;; (0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49)

catjam 2
😀 2
😂 3
teodorlu06:05:44

Litt i slekt med radix-sort, kanksje?

oddsor06:05:17

Det som er spennende er hvordan det går å sortere negative tall thinking-face