This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2023-10-18
Channels
- # announcements (12)
- # babashka (6)
- # beginners (62)
- # calva (3)
- # cider (41)
- # clerk (5)
- # clojure (192)
- # clojure-bay-area (1)
- # clojure-europe (14)
- # clojure-norway (97)
- # clojure-uk (6)
- # clojuredesign-podcast (4)
- # clojurescript (30)
- # code-reviews (7)
- # cursive (32)
- # datahike (4)
- # datomic (35)
- # docker (8)
- # emacs (8)
- # events (1)
- # fulcro (13)
- # helix (19)
- # hoplon (4)
- # hyperfiddle (37)
- # jobs-discuss (10)
- # membrane (11)
- # missionary (19)
- # off-topic (28)
- # polylith (8)
- # portal (10)
- # practicalli (8)
- # re-frame (31)
- # reitit (6)
- # shadow-cljs (39)
- # timbre (3)
- # vim (1)
- # xtdb (6)
Jeg skal velge å banne litt i kjerka, men du verden så digg det er med sql når du kommer fra mongoland.
(banninga er da at jeg burde jo sikkert sagt “Du verden så digg det er med datalog når du kommer fra sqlland”)
Dagens spørsmål. Jeg har denne app
-funksjonen med routes:
(defn app [req]
(case (:uri req)
"/" (h/home)
"/greet" (h/greet req)
"/htmx-demo" (h/htmx-demo)
"/htmx-demo-replace-button" (h/htmx-demo-replace-button)
(h/not-found)))
Det bør kanskje ikke gjøre det, men det irriterer meg litt at routes ikke er en map
eller noe slikt, definert utenfor app
-funksjonen, kanskje i et annet namespace enn server
. Særlig hvis det blir mange routes. Det ser jeg for meg at det kan bli, fordi HTMX trenger en eller flere routes for alle ting som skal skje i front-end.
Jeg har forsøkt å trekke ut routes til et map
, men sliter med å få med parametere til handlerne.
Så tenkte jeg at løsningen kanskje er å bruke higher-order funksjoner, eller grøss en makro… Men det er jo slippery slope til Compojure eller Reitit.Jeg har prøvd meg på noe slikt (higher-order funksjoner):
(defn create-router [routes not-found-handler]
(fn [req]
(let [handler (or (get routes (:uri req)) not-found-handler)]
(handler req))))
(def routes
{"/" #(h/home %)
"/greet" #(h/greet % (:params req))
"/htmx-demo" #(h/htmx-demo %)
"/htmx-demo-replace-button" #(h/htmx-demo-replace-button %)})
(defn not-found [req]
(h/not-found req))
(def app (create-router routes not-found))
Eller noe slikt (makro):
(defmacro defroutes
[routes]
`(fn [req#]
(let [route# (get ~routes (:uri req#))]
(if route#
(route# req#)
(h/not-found req#)))))
(defn greet [params]
{:status 200
:headers http-headers-default
:body (-> (c/build-greet-body (:name params))
build-page)})
(def app (defroutes
{"/" h/home
"/greet" greet
"/htmx-demo" h/htmx-demo
"/htmx-demo-replace-button" h/htmx-demo-replace-button}))
Men det føles litt rotete (og virker heller ikke).én ulempe med et map er at du da får kun oppslag, på sikt trenger man fort noe pattern matching osv
Poenget tidligere i kanalen her var "gjør det så lett som mulig frem til du kjenner på smerten" - dette for å få en god forståelse av basics. 😅
Det er interessant at det er vanskelig for en newbie å vite når tiden er moden for å "eskalere" fra basic clojure.core
funksjoner til et enkelt bibliotek, eller fra et enkelt bibliotek (Compojure) til et mer sofistikert bibliotek (Reitit). "Er det nå jeg bør dra frem denne her, tro?"
Generelt liker jeg idéen å begynne så enkelt som mulig å kun "eskalere" ett hakk oppover når behovet melder seg, typ når smerteterskelen er nådd. Men smerteterskelen til en nybegynner som meg er antagelig betydelig lavere enn for en hardbarka eventyrer som noen av dere, hehe.
Min mening: Å ha rutene "på utsiden" har ingen verdi annet enn å gjøre det litt vanskeligere å se det totale bildet, og den bittelille case
-en din er ikke i nærheten av for lang til å kreve tyngre skyts. Men det er nå min mening 🙂
Enig i det, ja! Jeg holder på å lage en template til vår interne verktøy "Flash" (wrapper GitHub) som folk (eller jeg) kan bruke for å komme raskt i gang med en ny Clojure web app.
Så da er spørsmålet om jeg bør inkludere en router eller ikke i den konteksten. Kanskje ikke.
Jeg opplever det kanskje som litt vel prematurt å skulle generalisere noe før man har noe 😅
Konteksten er at jeg ser for meg en Clojure intern workshop i fremtiden, som bygger på disse erfaringene her. Og kunne peke på et repo/template som folk kan bruke i workshop og etterpå.
Men, ja, det er absolutt bedre å bygge det opp selv fra scratch har jeg jo erfart nå.
Du vil kunne lage en mye fetere workshop hvor du heller ber folk om å bygge templaten selv fra ingenting
Basically: La de andre gjøre det du nå har gjort. Det er i skrivingen at læringen er 🙂
var nettopp det jeg gjorde på Kotlin-meetup her om dagen, folk likte godt å se både hvor lite som skulle til, og det virket også som det var gøy for folk å se hvilke komponenter en webapp faktisk er bygget opp av (typ, hva trenger man egentlig for slags biblioteker og boilerplate for å skru sammen en webapp?)
trenger ikke hundretusener av linjer med Spring for å få env-spesifikke configfiler, routing, databasemigrasjoner og SQL-spørringer, holder med ~100 linjer kode du skriver selv 🙂 https://github.com/augustl/2023-10-kotlinmeetup/blob/28f9aeeafe60ef1214daab03ac69df7c89e74c08/src/main/kotlin/kotlinmeetup/Main.kt
All erfaring fra andre språk og communities slåss mot meg: "Lag en template!" og "Bruk et library over en lav sko!" og "Lag et framework!" 😂
Det å modifisere eller bli kvitt godt innarbeidede tankesett og vaner viser seg å være svært vanskelig.
Tenk så deilig å bare lage en deps.edn
med {}
i, og så kan du skrive Clojure-kode med det samme i REPLet, og så bygge på derfra fra scratch.
Jeg tror egentlig dette er første gangen jeg har 100% forståelse for all koden i hele prosjektet mitt (bortsett fra internals på HTTP Kit, Ring og Hiccup). Og jeg har aldri jobbet med en web app med kun tre dependencies (hvis vi teller Clojure, HTMX og Bulma så blir det seks da).
Bare det å ha full oversikt over hvilke dependencies man har er stort nok i seg selv, særlig hvis man teller med implicit dependencies (dependencies av dependencies). I et C# .NET prosjekt er det fort flere titalls eller flere hundre dependencies som man ikke vet hva er.
Jeg lagde et flunkende nytt spring-prosjekt nå i forrigårs og dependabot advarte om 9 sårbarheter 🤷 Spesielt morsomt at graphql-pakken i Spring inneholder en versjon av snakeyaml (yaml?) som har noe sårbarheter i seg.
Jøss, det var jo enkelt. Med null forkunnskaper tok det ca. 1 time å lage build.clj
, bygge- og kjøre web appen min som en .jar
fil. Fett.
Nå må jeg bare finne ut hvordan jeg pakker .jar
fila inn i et Docker image og deployer til Kubernetes (i Azure) via GitHub Actions 🙂 Så er milestone 1 nådd.
random tanke: venter fortsatt på “frontend-rammeverket” som løser brukernes #1 irritasjon - data forsvinner. Selvfølgelig forsvinner data når det fundamentale i teknologien er å lagre brukerdata (skjema-input) i RAM, og at ingenting blir persistert før man har domene-gyldig data i databasen. Skulle likt å se en arkitektur/rammeverk som tok vare på all user input på et eller annet vis
@christian767 og jeg har sparket i gang en liten teknisk blogg fra teamet vårt med deilige gule parenteser. Første bloggpost er "Lange, flate filer", om en grovt undervurdert teknikk for å lage nettsider. 😊 https://parenteser.mattilsynet.io
Klarte ikke komme på noe, men Team Mat. Føler at det ligger en del vitser i det navnet.
Men, fra spøk til alvor. Setter stor pris på at dere fronter enkle løsninger. Min drøm har lenge vært å starte mitt eget selskap. Navnet har vært klart lenge: Assum Antiteknologi. Vi leverer stort sett «Nei».
trenger en liten clojure-boost igjen, jeg er litt der nå at next.js + vercel er så digg med hot reloading og server-side generering av HTML med infinite cache som default at jeg trekkes i den retningen for statiske websider (og så er det trivielt å lage ikke-statiske ting om det behovet uforutsett skulle melde seg)
Våre front-end utviklere er også all-in på Next.js, det er visst "the shit" i JS-land denne måneden.
Så hot at vår nye nettbutikk har fått navnet "NextCom" 😅 Fordi den bygger på Next.js
Blir glad av å se interressant informasjon i god, gammel, bloggform! Er det lov å ønske seg en RSS strøm?
@schmandle absolutt! Står på lista. Vi er på litt MVP-nivå her 😅
er jo fint å få auto all the things, inkludert auto-bygg når man pusher til git, egne URL-er for brancher, og generering av HTML build time og i det hele tatt. Hadde jeg hatt tid ville jeg undersøkt om det gikk an å lage et clojurescript-lag oppå nextjs sin stack
Jeg vil også minne om at i Ardoqs 10 års historie, har vi brukt minst fire “rendre html” teknologier. Det viser skifte av teknologi en gang pr 2.5 år. Tenk på det neste gang du går all-in på et frontend rendre-rammeverk.
Samme her, Backbone.js → Angular.js → Vue.js → React.js → Next.js… Med og uten TypeScript. Det tar aldri slutt 😅
Det jeg ikke skjønner er hvorfor frontend økosystemet ikke innser dette og skriver kode deretter.
Tipper at kontinuerlig påfyll med unge folk med mer mot og selvtillit enn erfaring i hvert fall er med på å forklare saken
samtidig kan vi være glade for at vi kan skrive next-apper i dag og ikke backbone-apper.. Ting går om ikke annet på sett og vis fremover 😄
Ja, det er veldig kort "kulturell hukommelse," front-end folk begynner og slutter innen 2 år, og de nye vil skrive om alt fra de gamle, etc.
@U01PE7630AC @U04V5VAUN i deres tilfeller, har det vært CTO-er eller arkitekter som har kontinuerlig vært med og stått i bresjen og/eller godkjent sånne endringer? Eller har det vært en grasrotgreie som bare har blitt gjort?
Det neste store tipper jeg blir HTMX type ting. Jeg hører prat og murring om det i front-end land her i alle fall.
Jeg har forsøkt å foreslå til front-end gjengen vår å hoppe bukk over Next.js og gå rett til HTMX for det meste.
Haha! Jeg var også en sving innom Python/Django og Ruby/Rails. Det minner litt om det, ja.
@U0MKRS1FX Det har alltid vært en grasrotgreie. Vi har ikke hatt (interim) CTO før i august i år, faktisk! Men vedkommende er ikke spesielt teknisk egentlig.
Nå vet ikke jeg helt hva en CTO skal drive med, men det hørtes instinktivt ikke bra ut i mine ører
Vi har en intern utlysning for permanent CTO nå i disse dager, men det er nok en mer sosiopolitisk/diplomataktig stilling egentlig.
Vi har en veldig dyktig Principal Software Engineer som er med på de fleste slike tekniske avgjørelser da. Han er interessert i det meste, også Clojure.
Hos Mattilsynet så har vi en radikal greie med at utviklerne kan gjøre sine egne betraktninger om slike ting. 😅
Alle jeg har vist Clojure synes det er kult men sier også at det ser svært fremmed og vanskelig ut. Folk blir litt skremt. Men noen er villige til å prøve det ut.
Hos oss har utviklingen vært drevet fra et seniornivå? Jeg liker å tro at vi har sett at kodebasen er vond å jobbe i, tenkt litt på hvordan vi ønsker at kodebasen skal være, og valgt teknologier deretter. De eneste aktive teknologivalgene som har skjedd i min tid er React og RxJS
Mattilsynet er jo velsignet med minst et team bestående av folk som kunne valset inn som CTO i et hvilket som helst firma :)
Det som er litt synd er at store bedrifter ofte bruker "executive recruiting" byråer for å finne CTO, og stillingene blir ikke utlyst. Byråene som driver med headhunting er ikke tekniske nok, og de overbeviser ikke-tekniske ledere i bedriften om å ansette en semi-teknisk CTO med lite hands-on erfaring og hullete kunnskap. Slike kandidater er ofte karismatiske og kan nok til å virke overbevisende ovenfor ikke-tekniske forretningsfolk og styret, som bestemmer retningen og hva som får budsjett. Da kan hele utgangspunktet bli feil.
Jeg tror faktisk at det kan funke greit hvis CTO’en er ydmyk mhp det de ikke kan og lytter til sine tekniske ledere.
Jeg tror det er sykt tungt å være en teknisk CTO i et større selskap dersom man er for lett på det kommersielle/ politiske.
Det som gjør vondt verre er at de best kvalifiserte kandidatene, når en slik stilling først blir utlyst, often ikke er utadvendte og karismatiske nok til å overbevise CEO og styret om at de er bedre enn mindre kvalifiserte men mer karismatiske kandidater. Så da ender ofte bedriftene opp med å ansette feil person i slike scenarioer også.
De farligste tekniske lederne er de som kan nok til å virke overbevisende men som egentlig ikke vet hva de prater om.
Jeg tror det er sykt tungt å være en teknisk CTO i et større selskap dersom man er for lett på det kommersielle/ politiske.@U04V5VAUN, der peker du på hovedårsaken til at jeg ikke har søkt på CTO stillingen, selv om flere på teamet har spurt meg om det.
Det er for tungt å være en teknisk toppleder i en ikke-teknisk organisasjon hvor diskusjonene er fokusert på ting som burde være ikke-teamer.
Jeg har også tenkt at CTO i en startup er en offensiv stilling, mens etterhvert som bedriften blir større blir den mer defensiv. Jeg har ikke tid/ork til å forsvare hvorfor Scrum suger for folk som uansett ikke skjønner hva de prater om.
@U01PE7630AC er dette en CTO stilling i Elkjøp “globalt” eller noe litt mer lokalt?
stakkars Magnar, bare å nevne frontend-tech var nok til å sparke i gang en diskusjon 😅 :smiling_face_with_3_hearts:
@U04V5VAUN Den er "global" for Elkjøp (altså, i Elkjøp Nordic, der jeg jobber), men ikke "global global" som i Currys (eieren av Elkjøp).
Right, men da kommer det sikkert masse sånn IT ops (hva slags maskiner skal de ansatte ha og greier) under den stillingen?
Elkjøp Nordic har ca. 450 fysiske butikker og 4 nettbutikker i 7 land: Norge, Sverige, Danmark, Finland, Island, Grønland og Færøyene. Det er ca. 15.000 ansatte på tvers av alle landene. Jeg tror vi er Nordens største retailer uavhengig av bransje.
Ja, sannsynligvis den typen ting også. For ikke å snakke om hardware og teknisk infrastruktur i alle fysiske butikker.
Ja, det er egentlig en ikke-teknisk/politisk/diplomatisk/HR-aktig stilling i teknisk drakt (tror jeg) :man-shrugging:
@schmandle Nå er det RSS på parenteser-bloggen også. 😊 https://parenteser.mattilsynet.io/atom.xml
@schmandle Nå er det RSS på parenteser-bloggen også. 😊 https://parenteser.mattilsynet.io/atom.xml