This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2023-10-25
Channels
- # announcements (22)
- # babashka (9)
- # beginners (33)
- # biff (12)
- # calva (17)
- # cider (64)
- # cljdoc (3)
- # cljfx (16)
- # clojure (125)
- # clojure-bay-area (14)
- # clojure-europe (15)
- # clojure-norway (64)
- # clojure-uk (2)
- # clojurescript (7)
- # conjure (1)
- # core-async (4)
- # cursive (6)
- # data-science (14)
- # datahike (8)
- # datomic (6)
- # defnpodcast (4)
- # emacs (5)
- # events (1)
- # hyperfiddle (15)
- # leiningen (17)
- # lsp (8)
- # membrane (27)
- # off-topic (25)
- # podcasts-discuss (4)
- # polylith (6)
- # portal (21)
- # reagent (11)
- # releases (1)
- # shadow-cljs (36)
- # slack-help (2)
- # sql (1)
- # squint (131)
- # testing (12)
- # xtdb (7)
Hur tĂ€nker folk kring skĂ€rmar? Har en 32" med 60hz och tittar pĂ„ att eventuellt uppgradera. Ăr lite av en djungel dĂ€rute med mĂ„nga val
Jeg har en LG Ultrafine 5k, ekstremt fornĂžyd med den. Tror den er 28". Mer enn stort nok for meg.
Har nokon brukt/testa e-ink skjerm? For bruk til programmering?
Nei, men jeg har vĂŠrt nysgjerrig pĂ„ Ă„ teste ut https://shop.boox.com/collections/all/products/mira en stund! Den er bare litt for dyr đ
Jeg liker ganske godt disse ThinkVision skjermene. De funker godt med macOS og docken med kun én kabel til Mac-en. Jeg bruker begge skjermene som to skjermer. Den store delt vertikalt, og den "lille" delt horisontalt. Skjermen pÄ hÞykant er fin til monitorering av tjenester i Kubernetes, terminaler, diffing av lange kodefiler, etc.
Dagens utfordring: PrĂžve Ă„ forstĂ„ hva som foregĂ„r https://github.com/RutledgePaulV/kube-api/blob/master/kube-api-core/src/kube_api/core/kubeconfig.clj og https://github.com/RutledgePaulV/kube-api/blob/master/kube-api-core/src/kube_api/core/auth.clj, og trekke ut kun de bitene jeg trenger đ
inject-client-auth
i auth.clj
var da en voldsom multimethod! Noen av de lengste Clojure funksjonene jeg har sett sÄ langt.
Kanskje det er enklere Ă„ lese https://kubernetes.io/docs/concepts/configuration/ og implementere det selv fra scratch enn Ă„ forstĂ„ det der đ
ser det spikkes litt flis her for tiden, og det vil jeg vÊre med pÄ! hvilken av disse foretrekker dere? vi antar at get-recent-crossings
og add-vessel-name-to-crossing
er gode navn pÄ funksjoner
;; 1
(defn get-recent-crossings [vessel-names mmsis]
(if (sequential? mmsis)
(add-vessel-name-to-crossing vessel-names mmsis)
(add-vessel-name-to-crossing vessel-names [mmsis])))
;; 2
(defn get-recent-crossings [vessel-names mmsis]
(add-vessel-name-to-crossing
vessel-names
(if (sequential? mmsis) mmsis [mmsis])))
;; 3
(defn get-recent-crossings [vessel-names mmsis]
(let [mmsis (if (sequential? mmsis) mmsis [mmsis])]
(add-vessel-name-to-crossing vessel-names mmsis)))
;; 4
(defn get-recent-crossings [vessel-names mmsis]
(let [mmsis (cond-> mmsis (sequential? mmsis) vector)]
(add-vessel-name-to-crossing vessel-names mmsis)))
;; 5
(defn get-recent-crossings [vessel-names mmsis]
(add-vessel-name-to-crossing
vessel-names
(cond-> mmsis
(sequential? mmsis)
vector)))
MĂ„ vi ogsĂ„ anta at det er gode grunner til Ă„ sende inn bĂ„de en liste og ett element til samme funksjon? đ I sĂ„ fall syns jeg 1 var lettest Ă„ lese, og 2 gjentok seg minst, sĂ„ en av dem.
Jeg foretrekker 5, men er som @U07FCNURX mildt skeptisk til konseptet đ
Grunnen til at jeg ikke foretrekker nr 5 er fordi jeg aldri klarer huske forskjellen pÄ vec
og vector
Jeg lurte fÞrst pÄ hva "mmsis" betyr. "Maritime Mobile Service Identities!" Takk, Google! Alternativ 1 synes jeg ogsÄ var lettest Ä lese. Alternativ 5 hadde jeg formatert slik:
(defn get-recent-crossings [vessel-names mmsis]
(add-vessel-name-to-crossing vessel-names (cond-> mmsis
(sequential? mmsis)
vector)))
Jeg tenker litt DRY nÄr jeg ser 1. Jeg tror jeg synes det er rotete med forgrening inni funksjonskall, sÄ nei til 2. Jeg foretrekker nok 3 over 4, da jeg er mer komfortabel med syntaksen der. 5 virker rotete for meg.
@U07FCNURX Poeng! Jeg svarte 5 pÄ generelt grunnlag, for jeg liker cond->
til ish sÄnne ting. Men enig i at vec/vector er kjip.
Jeg blir sittende og lure litt pÄ hvilket navnerom disse funksjonene lever i. Og om koden kan gjÞres mer lesbar hvis man tar med navnerommet. Da kunne man kanskje kommet unna med kortere funksjonsnavn, feks vessel-location-info/recent-crossings
.
(jeg svarer ikke helt pÄ det du spurte pÄ!)
(defn get-recent-crossings [vessel-names mmsis]
(->> (if (sequential? mmsis) mmsis [mmsis])
(add-vessel-name-to-crossing vessel-names)))
Lanserer en 6. kandidat!selv om du gÄr for alternativ 0 mÄ du vel pÄ ett eller annet tidspunkt sjekke om du har en sequential eller ikke pÄ en eller annen mÄte? :thinking_face:
spÞrsmÄlets opprinnelse var at jeg under code review sÄ 1 og tenkte at jeg ikke likte dupliseringen. sÄ tenkte Ä foreslÄ 2, men da jeg sÄ den fÞltes 1 bedre. tror jeg vanligvis gjÞr 3.
à innfÞre en let her, som atpÄtil overskriver navnet pÄ parameteret, sorterer aller lengst ned pÄ min liste over foretrukne lÞsning.
@U013U475882 poenget mitt var at hvor enn du sitter med én mmsi og skal kalle pÄ en funksjon som tar en sekvens av mmsiér, sÄ hÄndterer du differansen der og inliner det med [mmsi]
Dette ble vel allerede er pÄpekt av et par andre lengre oppi trÄden. Jeg er ikke sÄ begeistret av funksjoner som har parametre som bÄde kan vÊre en sekvens og enkelt-elementer av en ting
Har forstĂ„else for at du anser dette som en liten avsporing av det opprinnelige spĂžrsmĂ„let altsĂ„ đ
Avsporinger er name of the game đ ser Ăžnsket om Ă„ hĂ„ndtere dette pĂ„ kallstedet.
Inspirert av det rett over, jeg mener Ă„ huske at bruken av let
er blitt diskutert tidligere. Synes dere at man bÞr forsÞke Ä unngÄ bruken av let
? Har dere noen for og imot?
En Ă„penbar case hvor let
er bra er hvis du skal bruke noe flere ganger. Typ:
(defn do-stuff! [thing]
(let [new-thing (add-stuff thing)]
(do-a! new-thing)
(do-b! new-thing)))
heller enn:
(defn do-stuff! [thing]
(do-a! (add-stuff thing))
(do-b! (add-stuff thing)))
Jeg skrev ganske nylig denne funksjonen:
(defn oggpow-link [{:keys [opts]}]
(let [pages-by-slug (->> (oggpow/pages)
(filter :uuid)
(map (juxt :slug identity))
(into {}))
choice (fzf (keys pages-by-slug))
unicad-discovery-host ""
host (cond (:local opts) ""
(:global opts) unicad-discovery-host
:else "")]
(when-let [uuid (some-> choice pages-by-slug :uuid)]
(println (str host "/by-uuid/" uuid "/")))))
SĂŠrlig fornĂžyd med bruken av some->
. Jeg har sett eksempler pÄ bruk av some->
fra cjohansen her i kanalen, men har egentlig ikke brukt some-> og some->> skikkelig fĂžr.
Hadde jeg skrevet eksempelet for noen mÄneder siden, hadde jeg kanskje brukt mer let
og if
i midten istedetfor.
Edit: det er ganske mye let
i koden over fremdeles, det er kanskje mulig Ä fÄ til mindre let
.1. Det er vanskelig Ä gi gode navn. UnngÄ let der det er unÞdvendig. 2. Det er lett Ä ende opp med Ä skrive lange let-statements som ligner overraskende mye pÄ imperativ programmering. Disse er sjelden idiomatisk Clojure.
Jeg tror at let
kan vÊre bra, selv om det ikke er strengt nÞdvendig, hvis det gjÞr koden mer lesbar. Men jeg tror og at nÄr man kommer fra imperative sprÄk er det lett Ä let
-e alt for mye đ
I tillegg til grunnene @U07FCNURX oppgir: let innfÞrer nye navn og gÄr pÄ bekostning av Ä kunne lese koden lineÊrt
Med "lineĂŠrt", tenker du da pĂ„ at koden blir mer skeiv? đ Vi foretrekker mer veritkal kode over mindre vertikal kode?
Jeg mener at jeg kan lese en funksjon fra topp til bunn i én pass, uten Ä mÄtte hoppe frem og tilbake for Ä sjekke hva ting er
We grabbed the two Norwegian Clojurians who missed my (allegedly) auspicious visit to Norway and forced them to do an episode with us https://soundcloud.com/defn-771544745/92-defnno-with-magnar-sveen-and-christian-johansen
Personally, I'm really glad you spent effort trying to reach "the poor Norwegians who are into clojure"! :hugging_face:
I'll use the chance to say thank you for expand-region.el :the_horns: It's been a stable part of my Emacs config for a long time bound to M-Ăž, and I use it every day. Thank you!
Er det denne "scope capture" du snakker om, @U07FCNURX? https://github.com/vvvvalvalval/scope-capture