Jeg er glad i en stor main-funksjon, men havner ofte på Integrant litt tidligere enn kanskje strengt tatt nødvendig for å få en god repl-opplevelse, særlig når det gjelder reset. 🙂

Ellers syns jeg det er greit å få oversikt over systemet med integrant takket være det store config-mappet.

En stor main-funksjon er også fin om man har lyst til å gå veien med native-image i graal også, selv om det er et nisje-case

(da må imports av nødvendige namespaces helst være gjort eksplisitt om jeg husker rett)

Integrant med system-config og alle implementasjonene i ett namespace er jo basically en "stor main-funksjon" med god tooling. Jeg liker det veldig godt.

Hm har du alle ig/init-key i samme namespace :thinking_face: Noe av grunnen til at jeg flyttet fra integrant til clip var at jeg mislikte alle ig/init-key rundt omkring, tenkte ikke på å samle dem engang 😞

Har ikke brukt clip så lenge, men syns det fungerer ganske greit også. De er jo ganske like 🤷 Er det noe fra integrant du savner i clip, @U55V0HZMJ?

@U55V0HZMJ du kan ha dem alle på ett sted, ja 😅

Aldri hørt om clip, jeg

Jeg bytta fra mount av samme grunn som deg @U55V0HZMJ, men den strør jo faktiske globals rundtom

Synes clip funker fint har, ikke noe å utsette på det (kommer ikke til å bytte tilbake selv om integrant er liksom mer mainstream). Jeg har en app jeg starter med flere forskjellige configs, så litt dynamisk lasting er det.

https://github.com/juxt/clip Forskjellen er vel egentlig i hovedsak at man ikke bruker defmethods, men skriver litt mer kodete konfigurasjonsfil. Den største nedsiden er kanskje at man kan være litt udisiplinert på hvor kodete konfigen blir 🙈

Jeg bruker EDN for config da og kaller funksjoner med fullt namespace.fn derfra. Kombinerer med https://github.com/juxt/aero/ for environment og passord fra aws-ssm osv

Litt morsomt å se den sammenligningen med andre bibliotek i dokumentasjonen til Clip. Føles som om man kan se Clojure-miljøet sin dialog med seg selv. 😅 “Dette er fortsatt ikke ‘just data’ nok!”

Kommer til å pusle med Clip en stund til, men jeg er fortsatt ikke sikker på om jeg liker at det føles som man ikke lenger tydelig ser “inngangene” til appen slik som man gjør med integrant sine defmethods 🤷

Hvordan integrerer du data fra AWS SSM med resten av Aero-konfigen, @U55V0HZMJ?

Jeg utvider aero/reader som dette

(defmethod aero/reader 'aws-param [_ _ param]
  (aero/deferred (aws/get-param param)))

Fiffig, takk! Bruker SSM her, men henter alle parameterene under en path (f.eks. ‘/vilect/production’) og setter dem sammen til et map, som jeg merger sammen med resten av konfigen. Aero virker jo veldig smooth og utvidbart.

Blir kanskje ikke den helt store forskjellen, men kanskje litt mer eksplisitt? Typisk har jeg ikke bare passord men også bruker som hører sammen med passordet. Eller private og public keys

Ja, enkelte konfigverdier hører sammen med andre. Jeg pleier å validere at hver enkelt komponent har fått sine konfigverdier i det komponenten starter.

confair har dette fint håndtert syns jeg 🙂

Synes ikke det virker nødvendig om du har

(connect #was-param "service.1.username" #was-param "service.1.password")

Ser at det (confair) kanskje løser et litt mer komplekse greier ja 😅

@magnars I Readme-en beskriver du hvordan man kan sjekke inn en kryptert dev-konfig i Git. Tar du denne praksisen helt ut og sjekker inn produksjonskonfig også?

Ja, vi har gjort det på lukkede repoer.

@U55V0HZMJ det er også hyggelig å få en ålreit feilmelding under oppstart, og ikke når man forsøker å connect'e på et vilkårlig senere tidspunkt.

Absolutt! I mitt tilfelle får du da vite at det parameteret ikke finnes under oppstart

Git har en helt fantastisk datamodell og et nokså ræva designet "porselen" over. Bruk magit 😄

fetch først, ta en titt på nye commits, så rebase

Ja, det er vel på tide at jeg lærer meg å bruke rebase. Det var faktisk sånn jeg kom på dette nå, fordi jeg satt og leste https://www.atlassian.com/git/tutorials/merging-vs-rebasing 🙂

https://thoughtbot.com/blog/git-interactive-rebase-squash-amend-rewriting-history#interactive-rebase var også ganske alright.

@U9MKYDN4Q For å bruke Magit må jeg vel først lære meg å bruke Emacs? 😅

Jeg har kjørt gjennom de interaktive guidene til Emacs, men kløner og fikler fortsatt fælt, og ender som regel tilbake i VS Code med Calva. Det er vel på tide å gi Emacs et mer helhjertet og langsiktig forsøk for å komme over nybegynnerhumpene.

Det er også mulig å bare bruke magit, slik som @U0MKRS1FX gjør.

haha jepp, can confirm, det er uslåelig 😄 Bruker faktisk magit i vscode litt og, den er nesten like bra (dvs, like bra og logisk bygget opp, men har ikke emacs-magi som masse keyboard shortcuts for å redigere i rebase-bufferet osv osv)

Haha! Jeg trodde Magit var en "eksklusiv Emacs greie" pga. tag line "A Git Porcelain inside Emacs."

Men da skal jeg sjekke det ut!

ja, den i vscode er en reimplementasjon av emacs sin

https://marketplace.visualstudio.com/items?itemName=kahole.magit

Option-x og g og så åpner et herlig magit-buffer seg 😄 Trykk spørsmålstegn når du er der for å se hvilke keyboard shortcuts som kan brukes

eller bare kjøre magit status manuelt

Jøss, den VS Code extension er jo laget av en nordmann til og med.

Du må bare lese manualen godt nok: https://git-man-page-generator.lokaltog.net

https://hackernoon.com/how-the-creators-of-git-do-branching Ett annorlunda sätt att bruka git på, som jag har funnit mycket nytta i. Kör en anpassad version av den

Populariteten av https://stackoverflow.com/questions/18126297/when-to-use-the-no-ff-merge-option-in-git (10 år siden) vitner også om at enkelte ting er forvirrende.

haha samme, jeg har fått overlord-status på stackoverflow ved å være tidlig ute med denne

I 2013 eller 2014 leste jeg faktisk hele https://git-scm.com/book/en/v2, men jeg har glemt det meste av de mer avanserte tingene 😂 Hos forrige arbeidsgiver hadde jeg ansvaret for å migrere ~100 repos fra TFS (pre-DevOps) til Git på en fysisk server inne på kontoret (før vi brukte GitHub) og bevare all commit-historikken. Da støtte jeg på mye rart av problemer. Men i dag bruker jeg stort sett bare pull, checkout, add, commit, push, config, status og log, fordi vår CI/CD påtvinger feature branches med automatisk squashed merge uansett.

@U0MKRS1FX, våre Stack Overflow cake days er ganske nære hverandre da, hehe!

husker ikke helt kilden min til git-forståelsen, men ganske tidlig grokka jeg “datamodellen” til git og klarer å se forbi det rare CLI-et

tror jeg så en av Linus sine egne talks elns

hva i “pekere til commits (brancher, tags, …) som igjen peker på en kjede med tidligere commits som har SHA-en til tidligere commit som parameter til seg selv” er det nå denne kommandoen gjør. Eller noe sånt 🙂

å prøve å bygge git-forståelsen sin på CLI-et blir jo som å prøve å forstå hvorfor en baby gråter, masse skjulte variabler i en black box

Den artikkelen du delte var svært interessant, @U0545PBND! Interessant at utviklerne av Git bruker 4 langlevde branches, og merger topic branches til flere av dem, etc.

Och när vi ändå är inne på git

https://cbea.ms/git-commit/

Följ den artikeln. Du kommer tacka dig själv ett år senare när du undrar vad det var du gjorde

Nice, @U9MKYDN4Q! Jeg tror det var du viste meg noe lignende tidligere (som jeg delte i https://stackoverflow.com/questions/17332448/how-to-get-all-values-for-a-given-key-in-a-nested-structure-in-clojure/76434666#76434666).

Veldig kult!

Min neste drøm er å få støtte for #C68M60S4F i Portfolio, men vet ikke om jeg noensinne for tid for det…

Jeg kan sikkert bistå litt 😊 hva er det som kreves?