This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-02-08
Channels
- # announcements (14)
- # babashka (12)
- # beginners (140)
- # calva (2)
- # cider (22)
- # clj-commons (14)
- # clj-kondo (49)
- # cljdoc (34)
- # clojure (92)
- # clojure-europe (41)
- # clojure-france (2)
- # clojure-new-zealand (2)
- # clojure-nl (2)
- # clojure-norway (60)
- # clojure-uk (17)
- # clojured (2)
- # clojurescript (7)
- # community-development (3)
- # conjure (2)
- # cryogen (13)
- # cursive (4)
- # data-oriented-programming (2)
- # datahike (5)
- # datomic (12)
- # defnpodcast (10)
- # events (2)
- # fulcro (20)
- # gratitude (3)
- # honeysql (4)
- # introduce-yourself (3)
- # jobs (10)
- # lsp (58)
- # malli (12)
- # missionary (19)
- # off-topic (8)
- # pathom (18)
- # podcasts-discuss (1)
- # polylith (41)
- # releases (1)
- # remote-jobs (3)
- # shadow-cljs (52)
- # spacemacs (1)
- # sql (37)
- # xtdb (19)
Er det noe annet vi må gjøre i forkant, egentlig? Eller er det bare å trykke "ja" i meetup og dukke opp?
Takk for lunsj-slabberas i dag! Var første gang på Clojure-lunsj for meg, og jeg ser allerede fram til neste gang. Takk for hyggelig velkomst, god prat, finfin mat og godt selskap.
hva tenker folk om å lage sine egne sånne små "stdlib ++" varianter til sin egen kode? Ofte vanskelig å navngi dem. Men de kan jo være veldig kjekke å ha
Lager sånne hele tiden! Synes det er vanskelig å si om de bør være i en liten utils.clj eller bare private funksjoner i samme namespace. Har blitt mer glad i "slettbar" kode i det siste.
Det er rart med sånne “generelle” funksjoner. Mye av det vi gjør er å transformere data i format A over til format B. Og det er mange veier til Rom. Ofte, men sier ikke at det er tilfelle her, kommer slike “generelle” funksjoner som den over til ved at man tar en omvei. Laget slik den over er laget, så ser de veldig generelle ut, men de er egentlig ikke det. Jeg tror jeg bruker slike funksjoner som en slags indikator på at det finnes en bedre vei fra A til B.
Lyst til å komme med en sterkere påstand en "ofte"? (I prinsippet er jeg enig, jeg har oppdaget mange ganger at jeg kunne løst sånt bedre med 2-3 funksjoner fra standardbiblioteket) Edit: redigerte du bort "ofte"? 😄
Dette er funksjoner som vi bruker relativt ofte i Ardoq, men som ikke så fryktelig generelle, men som vi bruker fordi vi ikke har en skikkelig database, så vi må gjøre endel joins i Clojurespace.
Jeg skrev en hel del slike funksjoner for noen år tilbake, men kan ikke huske sist gang jeg gjorde det nylig. Mistenker at jeg nå oftere bare bruker clojure.core direkte.
Som et enkelt eksempel så pleide jeg å syns det var skrekkelig irriterende at det ikke fantes en (first pred coll)
, men er ikke lenger irritert over det. Bruker (first (filter pred coll))
og går videre med dagen min.
Som jeg skrev mer om her 🙂 https://www.kodemaker.no/blogg/2019-07-gammelt-triks-ny-kontekst/
Fint skrevet! Kjenner meg igjen i min egen kode. Var veldig glad i mange små funksjoner før, hadde det for meg at det gjorde koden min selvdokumenterende. Men effekten var at jeg måtte hoppe unødvendig mye rundt.
Christine hade en veldig fint rant om akkurat det 🙂
Men, @teodorlu jeg heller nok litt til din hang til å legge dem i det ns’et jeg først begynner å bruke dem og så heller flytte de ut til et felles sted hvis jeg begynner å se dem over alt. (set (map id xs))
var en sånn greie jeg etterhvert så over alt.
Kanskje forskjellen er om man ser et mønster over alt i kodebasen, så kan det være gunstig å mekke en funksjon for det, mens hvis du ser et bruk av en funksjon som ser generell ut, så kanskje man skal vente med å putte den i fellesområdet inntil man ser om det dukker opp flere brukstilfeller?
Men disse har jeg kopiert stort sett inn i alle prosjektene jeg har vært i opp gjennom årene: min-by
og max-by
. Får alltid mark av å se (first (sort-by ...))
😄 https://gist.github.com/8b71aaae0feb445643fabdbb9d776825
Problemet nå man er flere som jobber på en større kodebase, så kan det være vanskelig å oppdage disse felles greiene
Jeg vil jo si at (set (map id xs))
er 100% akseptabelt å ha mange steder i koden. Det er lett å lese og krever ingen nye navn man må ta inn over seg.
Ikke uenig i det, men nå er det egentlig (set (map core/id xs)
og det begynte å bli litt kjedelig å skrive, pluss at id-set
er et ganske godt navn på det hele.
Det som fikk meg til å endelig lage "dash.el" var jo når jeg fant ut at Emacs Lisp faktisk hadde en filter-funksjon, den het cl-remove-if-not
.
med mindre add-keys
gjør om typen på collection, og da har jeg et annet forbedringsforslag 😅
Hva da rar cursor, jeg har hatt (setq-default cursor-type 'bar)
siden sikkert emacs 19.20 eller no sånt
:lint-as {liberator.core/defresource clojure.core/defn
ardoq.test.api/deftest clojure.test/deftest
clj-configurator.core/defconfig clojure.core/def
ardoq.test.helper/with-system clojure.core/let}
hvordan kunne man gjort en slik ting, da? Altså min drop-by-men-ta-også-med-elementet-før-der-den-droppa?
men akkurat her føltes det hyggelig å kunne lese et lite logisk navn og. Så tipper jeg at både andre utviklere og jeg selv om to uker ikke forstår hva meningen er med det navnet, da, men, kanskje
jeg tror nok at min normale løsning her ville være å gjøre akkurat det samme som deg, minus å gi det et eget navn