Clojurians Log v2
clojure-norway 2025-11-07
Morn!
Morn!
Gledelig fredag!
Jeg har lyst til å lage en webapp for å hjelpe kona med å drifte kaffebrenneriet sitt. Men jeg har vært borte fra koding litt for lenge etter at sønnen vår ble født, og merker at jeg har glemt en del ting. Appen jeg skal lage er et skjema for å registrere nye B2B-kunder, slik at de kan logge inn og bestille varer med sin rabatterte avtale. I tillegg må det være en admin-del der kona kan logge inn for å legge inn produktene sine og avtalene til hver kunde, motta bestillinger og lage en plan for kaffebrenningen sin. Hun bruker altfor mye tid på å registrere kunder og ta imot bestillinger via Google Forms, e-post og telefon i dag. På sikt vil jeg også lage en slags "subscription engine" med Stripe for B2C-kaffeabonnement, fordi hun har så små marginer og betaler altfor mye i lisenser og avgifter for Shopify-pluginen hun bruker (som heller ikke er særlig god). Først tenkte jeg å bruke Elixir og Phoenix (som jeg kan litt bedre), men jeg oppdaget at jeg ikke liker det like godt som Clojure. Det er kjapt å komme i gang med, men det er altfor mye "magiske greier." Hvilke ressurser og hvilken fremgangsmåte ville dere brukt for å få på plass en webapp i Clojure, når man er småbarnsfar og bare har 1-2 timer til rådighet sent på kveldene for å jobbe i fred og ro? Jeg har børstet støv av bøkene Programming Clojure, Fourth Edition (Beta) og Web Development with Clojure, Third Edition (som virker litt utdatert) for å gi meg selv en liten oppfriskning. Jeg setter stor pris på andre tips og råd 🙂 Baktanken min er å ha et reelt prosjekt jeg også kan bruke til å lære mer om Clojure. Og hvis det blir bra, kan jeg kanskje selge det til små og mellomstore bedrifter, for eksempel andre kaffebrennerier.
Jeg ville kjørt på application.garden. Html fra serveren med gode gamle html-forms. Minimal kompleksitet, og du kan bruke ferdige løsninger for login og utsending av epost. Operasjonelt er dette helt nydelig.
Takk! Ja, det er en av tingene jeg er mest usikker på: Hvor og hvordan deploye en Clojure-app. Det er så enkelt med https://hexdocs.pm/phoenix/releases.html og plattformer som http://Fly.io og http://Gigalixir.com
På Garden er det garden deploy.
Du trenger ikke docker, reverse proxy eller noe som helst, eneste konfig du setter er :nextjournal/garden i deps.edn.
https://mikrobloggeriet.no/ har kjørt på application.garden i snart to år, det har vært en ren fryd å jobbe med. To flere favoritt-features:
• garden repl gir deg prod REPL
• Du får montert opp persistent lagring (vanlig filsystem), der du kan bruke opp til 10 GB.
Putt en sqlite-database inn der, eller bare bruk et Clojure-map med duratom.
Hvorfor SQLite og ikke PostgreSQL? 🤔 Jeg hadde i utgankgspunktet tenkt å bruke Datomic, men lurer på om det blir for mye nytt for meg å bite over på én gang. Jeg har mer inngående kunnskap om SQL.
Er det noe innebygd støtte for det i application.garden? Må vel ha på plass noe synkronisering ifm skriving til fil
Mulig at application garden er kult, men det er lite som slår å sitte rett i prod-replet og bare jobbe fram greiene.
https://content-made-simple.org her er det jo minimalt med trafikk, men denne har da vært oppe i over seks måneder, og deploy mekanismen er å jacke inn i prod-replet og mekke kode.
Kult!
Hostes på tilsvarende en ec2 instans.
Kjente ikke til duratom. Siden det er en agent/`atom` så er vel synkronisering håndtert?
Jeg antar det. Siden det antagelig er penger involvert i kaffegreia er det sikkert lurt å ha en ordentlig base i bånn, men denne approachen gjør at du kan utsette alle de spørsmålene til du har funnet ut av hva du skal lage.
Jeg har liksom en gjeng med upåbegynte prosjekter fordi jeg ikke helt orker å starte med alle “greiene”.
Hva med DataScript? Det kan kanskje være en myk introduksjon til Datomic? https://github.com/tonsky/datascript/blob/master/docs/storage.md
Jeg ville ihvertfall ikke gått for noe annet en immutable database av noe slag.
Hvorfor SQLite og ikke PostgreSQL? 🤔Lettere å kjøre lokalt, lettere å kjøre i prod, lettere å operere (ingen ekstra prosesser), lettere å ta backup. Med SQLite på Garden laster du ned en fil (noe ala
garden sftp get db.sqlite), stempler filen med dato, og putter den i Dropboxen din eller noe. Ferdig.
Du må gjerne drifte postgres hvis du vil, men jeg fikk inntrykk av at du kanskje heller ville bruke tid med kone, barn og kaffe!
Duratom er enda enklere å starte med.> Mulig at application garden er kult, men det er lite som slår å sitte rett i prod-replet og bare jobbe fram greiene. Er det ment som et argument mot application.garden? application.garden gir deg prod-REPL ut av boksen.
Jo, men det er mye (svart) boks.
Om Datomic. Jeg synes Datomic er helt fantastisk, men det tar tid å sette opp. Hvis målet ditt er å lære datomic, lær Datomic. Hvis du vil starte å lage en webapp fort, kanskje vurder andre ting!
Jo, men det er mye (svart) boks.Jepp — din content-made-simple er mye mer uavhengig av folk sine beslutninger enn et alternativ på application.garden! Jeg synes for øvrig også å starte på en VM, sette opp prod-repl og gå er en super måte å sette i gang. Om det er en lett start eller ikke går vel litt på hva Leif Eric har prøvd / gjort før. Og da står du på bar bakke med ting som innlogging.
Jeg svarer igjen fordi jeg ikke synes det første svaret mitt var godt nok.
1. Sett av et kvarter.
2. Klon ned https://github.com/nextjournal/calendula/
3. Les README, installer garden og kjør opp appen med garden run.
4. Koble til REPL fra VSCode med Calva Connect to a running REPL in the project, velg deps.edn
5. Fikle med oppførselen, gi deg når kvarteret har gått.
Å lage noe fra bunnen av er super-lærerikt, men du må ta alle valgene. Arkitektur, biblioteker. Jeg har vært i denne situasjonen selv, og ikke fått framgangen jeg ønsket meg. Hvis jeg kunne gått tilbake i tid og gitt meg selv et svar, ville jeg gikk meg selv akkurat dette svaret. Da kan du raskt få gleden av å ha noe ekte i prod, og jobbe derfra.
Tusen takk for alle gode innspill! Leser på telefonen mens jeg er ute og går tur med hunden her 😅 Skal sette meg bedre inn i alle disse tingene dere er inne på og vurdere.
@teodorlu jeg tror jeg er hjertens enig og synes greia di med å sette av et kvarter høres genialt ut!
Garden har til og med Datomic local ser jeg. Da kan man jo faktisk bruke det som et utgangspunkt for noe "skikkelig" 😄
Takk for info, @christian767! Jeg har prøvd meg litt på Datomic to ganger og liker det veldig godt konseptuelt. Men jeg synes det var ganske vanskelig å forstå oppsettet og ble veldig usikker på om jeg gjorde ting riktig. Så jeg ble skremt overveldet av å måtte lære for mage nye ting samtidig og falt tilbake på SQL 😅 Men jeg vil veldig gjerne også lære meg Datomic og er villig til å gi det flere forsøk. Jeg tror det kan gi meg ganske mye «gratis» og være mer fremtidsrettet og enklere og vedlikeholde hvis jeg får det til å «clicke» i hue mitt.
Datomic er verdt innsatsen. Datomic har vært minst en like stor level up som Clojure for meg.
Med Garden slipper du å finne ut av det operasjonelle, og kan bare fokusere på å lære deg å modellere med Datomic, som er ekstremt nyttig. Den dytter deg også inn i globale nøkler med navnerom, ref mine tanker fra i går.
Jeg kan anbefale å se "Day of Datomic"-videoene: https://docs.datomic.com/resources/day-of-datomic.html
Jeg tenker det er verdt å bruke noen dager på Datomic, ja. Gitt at det vil gjøre mange ting enklere. Det er nok verdt å bruke litt tid på det up front. Jeg begynner der. Takk igjen for tips!
Jeg ville kanskje brukt noen dager uten datomic. Du er i startgropa. Du har en slags ide om hva du vil lage. Finn ut av hva det er, sånn at du får en ide om hva datamodellen burde være. Det er sykt mye lettere å gjøre dette med et atom enn med en database. Når du føler at du har kontroll på datamodellen, bruk et par dager på å implementere den i datomic.
Sånn rask sjekk: Hvilke entiteter/domene ting er det du ser for deg å lagre i databasen og hvordan henger de sammen. Før du kan svare på dette, ikke bry deg med å mekke database.
Det som er så fint med Datomic er at den modellen du kommer frem til i Clojure kan lagres akkurat sånn. Ingen impedance mismatch som med en sql-database. Så start gjerne med et atom, bare husk navnerom på nøklene 😊
Du kan bytte over til Datomic når du trenger joins 😅 finnes haugevis av frontender som har basically et map i et atom og hjemmelaget indeksering og joins 🙈
Så/hørte på «Part 1» av «Day of Datomic» nå mens guttungen sover og jeg vasket badet, hehe. Skal se på «Part 2» når jeg går tur med hunden om litt før ungen våkner. Det var opp kl. 06:00 for musikkskolen til guttungen, så blir det ut på café når han står opp. Her går det i ett! Takk og pris for mobiltelefoner 😅
Tenker jeg skal skrive ned alle entiteter/verdier/relasjoner før jeg starter på appen, slik @slipset foreslo. Det var en god idé. Teste ut modellen med «penn og papir.»
Minner meg om gamledager når min tidligere kollega og «mentor» i Funcom, Sergey Nenakhov, nektet meg å bruke en PC for jeg kunne skrive x86 Assembly og C med penn og papir. Fordi det var sånn hans gamle russiske professor tvang dem til å tenke på problemet før de hoppet inn i kode på Moscow University.
Ah! Det er en «hands-on/follow-along workshop.» Nice. «Part 1» gikk fint på farten, men for «Part 2» må vente til jeg sitter foran PC’n. Får ta kurset i lunsjpausene på jobb!
Begynte å drodle på datamodellen ved å prate/sparre litt med ChatGPT mens jeg er ute og rusler istedenfor da 😁
Resultatet av 15~20 min muntlig «dialog» med Perplexity AI mens jeg luftet hunden.
Ser noen dumme ting der når jeg skummer gjennom. Men allikevel en alright måte å rådumpe tanker til fremtidig bearbeiding når en ikke har hendene til rådighet.
Du får be om feedback når du har bearbeida det litt, jeg orker ikke å ha en samtale med AI chatboten din gjennom deg 😅
Mange takk! Ja, ikke bruk noe tid på det halvbakte rælet der 😅
https://youtu.be/YSgTQzHYeLU var fantastisk, @magnars. Du er god på å forklare ting på en enkel måte som vanlige folk kan forstå. Jeg har tydeligvis ikke fulgt med og gått glipp av den når den kom ut.
Mornings
mrn
God fredag!
Morn! God fredag ja!
Morn!
På vei hjem fra jobb skravla @teodorlu og jeg om modellering og hva vi får ut av Clojure. Vi var ganske enige om at nøkler med navnerom er en av de virkelig store "unsung heroes" i Clojure. Jeg vil gå så langt som å påstå at nøkler med navnerom er en av de største enablerne for oversikt, forutsigbarhet, god modellering og god arkitektur i vår kodebase. Det er litt vanskelig å kvantifisere akkurat hvorfor, men én ting er i hvert fall klart: En nøkkel med navnerom lar meg forstå hva étt diskret datapunkt er uten å trenge å bry meg om mappet/objektet/recorden det kom i. Uten navnerom må du først forstå alle dataene du fikk og hva slags type ting de representerer, så kan du begynne å forstå hva bestanddelene er.
føler'n. Nøkler med navnerom løser sikkert 80% av problemene som gjør at folk innfører et typesystem
er vel en "Hickey-ism" her, i en eller annen talk snakker han om aggregater som et problem, og at det er absurd å bare kunne snakke om hjulet på en bil i konteksten av bilen
Dette er en kjempegod egenskap for et dynamisk språk og noe jeg drømmer om å få jobbe med her i mitt statiske klassebaserte univers. (har et mål om å komme dit altså) Stuart Halloway snakker om core values til Clojure i en gammel presentasjon hvor han bl.a. snaker om "extensible maps" eller noe i den duren. Men jeg har glemt hvilken presentasjon det var. Noen som husker?
Nøkler med navnerom er 🤌! Du trenger ikke vite konteksten du er i eller hvor dataene kommer fra. Du har alt tilgjengelig i navnet!! ✨
Nøkler med navnerom reduserer også mengden mapping og redundante navn i kodebasen. Ettersom data er definert på fact/attributt-nivå så er et :serveringssted/navn alltid et :serveringssted/navn. Hvis du ikke har navnerom på nøkler og heller bruker kompositter (maps, records, klasser) som abstraksjonsnivå, så vil det bli fristende å bytte navn på attributtene for å prøve å tilpasse dem konteksten sin. Altså at man gir navnene forsøk på navnerom, feks {:fornavn "Christian"} på en person og {:abonnent-fornavn "Christian"} i en representasjon av et abonnement.
En annen klassiker er ett navn i databasen (`created_at`), et annet i backenden (`:created-at` ), et tredje i API-et (`createdAt`) og hvis du er skikkelig heldig: ett fjerde i frontenden (`thingCreated`). Hvis du er heldig er det bare bike-shedding som i eksempelet mitt, er du uheldig så heter de helt forskjellige ting. Med Datomic, Clojure og namespaced keys trenger vi bare ett navn. Det gjør det ganske mye lettere å forstå hva noe er.
Morn!
Morn!
Morn
Morn!
God morn :)