Jeg står opp 05:30 hver dag 😅 Men det er ikke alltid jeg roter meg inn her før jeg kommer på kontoret.

Har ikke pleid å bruke noe bibliotek utover http-klient og kryptering. Hadde vært interessert i å høre hvilke problemer som løses av et eget bibliotek for dette!

Det er bare nesten riktig, for vi har brukt en av buddy-bibliotekene til JWT signering og verifisering 🙂

Men ellers enig

Hva med SSO (SAML) eller OIDC og andre OAuth-behov?

Bruker buddy-auth til session-håndtering i webappen. Ellers ikke noe. (Bruker ikke SSO eller OAuth, det skal sies.)

Har implementert OIDC selv.

https://github.com/sikt-no/clj-jwt finst også, me nyttar det eit par plassar til verifisering av tokens

Buddy fungerade bra och var enkelt att utöka då det använder protokoll för allt viktigt

@U06BU6Z44 Sist jag tittade (för 3 år sedan), så fanns det inget i clj space för SAML. Vi använde ett java bibliotek istället

I was lazy and used Google Login in my app. Using Buddy-jwt for the necessary pieces there. You could also offload it to a SaaS such as https://clerk.com/ …

Eg skreiv følgande greie (`future macro`) for å sjekka at alle threads fullfører i ein test:

(def ^:dynamic *active-futures* nil)
(def ^:dynamic *max-active-futures* nil)
(def ^:dynamic *fut-map* nil)

(defmacro future
  [& body]
  (let [info (assoc (meta &form) :file *file*)]
    `(let [info# ~info
           body-fn# (bound-fn []
                      (try
                        (when (some? *active-futures*)
                          (swap! *fut-map* update info# (fnil inc 0))
                          (let [new-cnt# (swap! *active-futures* inc)]
                            (swap! *max-active-futures* (fn [old#] (max old# new-cnt#)))))
                        ~@body
                        (finally
                          (when (some? *active-futures*)
                            (swap! *fut-map* update info# dec)
                            (swap! *active-futures* dec)))))
           f# (clojure.core/future (body-fn#))]
       f#)))

(defn report []
  (let [v @*active-futures*]
    (if (not= 0 v)
      (do
        (doseq [[{:keys [line _column file]} cnt] @*fut-map*]
          (when (not= cnt 0)
            (log/error "Offending future" (str "(" (last (str/split file #"/")) ":" line ")"))))
        (throw (ex-info (str "Still " v " active future(s)") {:count v})))
      (log/debug "All futures exited. Max was:" @*max-active-futures*))))

(defn with-futures-check [f]
  (let [cnt (atom 0)
        max-count (atom 0)
        fut-map (atom {})]
    (binding [*active-futures* cnt
              *max-active-futures* max-count
              *fut-map* fut-map]
      (f)
      (report))))

> Edit: 41 linjer er innafor? 🙂 Jeg vil si ja! Kanskje “én linje til én sidehøyde” er bedre å si enn “ca 1-10 linjer”.

Jeg er imponert over at du fikk til å skrive makroen i det hele tatt! Både makroer og dynamiske variabler.

> Kanskje nokon har forslag om betre måte å gjera dette på? Jeg melder pass.

Janei, janei. Eg er generelt imot å skriva makroer, særleg som skal leva i prod-kode, men dette får vera eit unnatak.

For koden din var vel kun for å “gi observability” og skulle kun brukes i tester?

Da tenker jeg i alle fall intuitivt at det er bedre å ha informasjonen enn å ikke ha den — uavhengig av om koden er skrevet med makroer eller ikke.

Ja, det er for observability ja. Koden vert verande der også i prod, men desse variablane vil då vera nil, så det vert i praksis ein vanleg future (med bound-fn).

synes det var litt mye metodekall i snutt 2. Men jeg skjønner jo at dette skal funke på alle binærfiler. Og jeg skjønner at det gir mening å kjøre SHA-1-hashing i inkrementer, ikke nødvendigvis hashe hele binærfilen på én gang.

Merk: dette er kode for å ilustrere hvordan man ikke skal gjøre passord. Koden brukes til å lage regnbuetabeller for å slå opp passord fra SHA1(passord). Så man kan forklare hvorfor man trenger salts. Fulltekst: https://github.clerk.garden/teodorlu/lab/commit/12c6c2518c23bd9899f85cd456e22386c172a4f7/src/rainbow_tables_2.html

All of https://github.com/hyperfiddle/electric is built on Missionary. I have never used it but it looks very interesting. F.ex. thx to handling both discrete events and continuous streams, and for avoiding FRP glitches which our RxJs suffers from. I bet it is rock solid by now.

Of course none of that means that it solves any problem you really have 🙂

> Of course none of that means that it solves any problem you really have 🙂 > Nope! Sometimes learning new things require a leap of faith. But you're right - I've been trying to find something I want to build with missionary or Electric, but I've come up short.

Jeg har prøvd spec.alpha og malli — men ikke gjort en stor innsats, og ikke følt at jeg har fått noe ut av det ennå. Liker at malli-spesifikasjoner bare er data. Hypotesen er at malli kan være fint i kanten av applikasjonen min til validering og coercion.

Det är en nackdel att clojure.spec är macrobaserat. Gör det svårt att utöka. Metosin började med malli efter att ha försökt sig på att förbättra spec utefter de behov de hade och till slut gav de upp. Att malli är databaserat är också en fördel, då du kan serialisera det och spara undan det

> malli är databaserat är också en fördel Kan også legge til at malli har to datanotasjoner, en https://github.com/metosin/malli#vector-syntax (ala hiccup) og en https://github.com/metosin/malli#map-syntax (ala cljfx). Vektorer er konsise å skrive, men maps kan være enklere å generere / parse. Tror de har funksjoner for å konvertere mellom vektorer og maps. … Så finner jeg denne: > NOTE: For now, Map syntax in considered as internal, so don’t use it as a database persistency model. Så kanskje ikke lurt å gjøre seg for avhengig av maps helt ennå.

Jeg sliter skikkelig med å like clojure.spec må jeg si. Syns malli er generelt mye mer ergonomisk. Bruker det i det meste av småprosjekter jeg driver med for tiden (jobber tross alt ikke med Clojure)

Bruker forøvrig mest den vektorbaserte stilen

Et nice triks med malli er at om man bruker malli-spec som metadata i funksjoner så kan man faktisk legge til specs for validering av funksjonskall i tester uten å ha en malli-dependency i produksjon (det blir bare liggende noe vektorer og keywords i funksjonsmetadataen) Men litt av poenget med sånne libraries er vel å ha det i produksjon for å validere ting på vei inn (og ut?), så nøyaktig hvor mye man blir å bruke funksjonsschema er vel diskutabelt.

Eksempel:

(defn jeg-liker-bare-seqs-med-tall 
  {:malli/schema [:=> [:cat [:sequential :int]] [:sequential :int]]} 
  [xs]
  (map inc xs))

(jeg-liker-bare-seqs-med-tall [1 :a])

-- Schema Error --------------------------------------------------------------- NO_SOURCE_FILE:18 --

Invalid function arguments:

  [[1 :a]]

Function Var:

  user/jeg-liker-bare-seqs-med-tall

Input Schema:

  [:cat [:sequential :int]]

Errors:

  {:in [0 1], :message "should be an integer", :path [0 0], :schema :int, :value :a}

I’d say clojure.spec is out (as mentioned, not data based => not inspectable, modable). The “lessons learned” Spec 2 is still nowhere close to be finished, so IMO Malli is the best choice nowadays unless your needs are quite simple and thus spec 1 is good enough.

> Et nice triks med malli er at om man bruker malli-spec som metadata i funksjoner så kan man faktisk legge til specs for validering av funksjonskall i tester uten å ha en malli-dependency i produksjon (det blir bare liggende noe vektorer og keywords i funksjonsmetadataen) Takk for tipset, nyttig! Kan vera greit for biblioteker også. Og ... Gir det meining å setja opp "sladring" til/med clj-otel for dette? Kunne vore fint å kunna sjå f.eks. "funksjon X får feil/ugyldig input <cnt> ganger per dag".

Det hadde jo vært interessant å sette opp noe slikt! Jeg har puslet litt med https://github.com/BrunoBonacci/mulog som er litt samme greie (mangler foreløpig støtte for opentelemetry); det hadde jo vært kult å få instrumentert antall schema-feil Kunne bedt https://github.com/metosin/malli/blob/master/docs/function-schemas.md#instrumentation til å bruke en custom report-funksjon som dytter ut telemetri-eventer for eksempel?