Fra boka “Presentation Patterns” https://nealford.com/books/presentationpatterns.html er det en sterk anbefaling om å “never go meta”. Ikke fortell om hvor dårlig du har forberedt deg, hvor nervøs du er etc. https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=video&cd=&cad=rja&uact=8&ved=2ahUKEwj1m4axsOH_AhWASfEDHXVBBGYQtwJ6BAgFEAI&url=https%3A%2F%2Fvimeo.com%2F68327322&usg=AOvVaw3rfi8njkdANRkXwVXh0iJc&opi=89978449

Henger meg forøvrig på @christian767s ros. Veldig bra foredrag, du er engasjerende på scenen, har en type talk som jeg liker, du presenterer noe som er på siden av Clojure, men som likevel har litt med det å gjøre. Du burde forøvrig skaffe deg en klikker så du ikke er låst til maskina for å bytte slide. Slidene dine var drit bra!

Takk, setter pris på det! Enig om klikker. Jeg kjøpte én, men den var upålitelig på Linux. Ref nerver - med så utrolig flinke folk i publikum føltes det å gå på scenen å skulle snakke om hypertekst litt rart. Dette er det folk i salen som kan bedre enn meg. Og jeg har aldri presentert for Clojure-folk før. 🙌🙌

Husk at uansett hvem som er i salen, uansett hvile flinke de er, så er det din talk, din historie. Ingen andre kan fortelle den. Det er også konferansen som har akseptert talken, så hvis du holder det du lovet i abstractet, så er du trygg. Mitt eneste ønske når jeg gir en talk er at jeg håper folk ikke kjeder seg.

> lar dette seg live-kode? Bra mål på hvor mye "incidental complexity" som følger med Enig! Hvis det lar seg demonstrere godt på noen minutter, kan det være noen minutter som er fine å bruke. Jeg lurer ofte på "men hvordan er dette egentlig?". Ref https://gist.github.com/adamwiggins/5687294#make-it-real (Adam Wiggins): > Ideas are cheap. Make a prototype, sketch a CLI session, draw a wireframe. Discuss around concrete examples, not hand-waving abstractions. Don't say you did something, provide a URL that proves it.

Hmm, ville ikke RoR og andre frameworks med masse magic være bedre for det en Clojure?

Det spørs jo litt hva du ønsker å vise fram! Man kan få en ekte blogg opp på beina fort med ruby on rails! Se feks https://www.youtube.com/watch?v=Gzj723LkRJY. Men i den videoen hopper forfatteren (https://dhh.dk/) over mange ting. Den lærer ikke akkurat bort Ruby. Da ville jeg heller sett på noen jobbe i REPL. Feks https://youtu.be/XDjBtkd4orw?list=PLaN-rC-CjQqDu1AVhGdGOoEqsSAhd2W6t&t=709. Her skjer det ingen kodegenerering, han skriver ("henter fra historikken") all koden han bruker. Mer fokus på koden ("koden er ekte"), mindre fokus på "produktet". Eller https://youtu.be/KKvancXJJJg?list=PLaN-rC-CjQqDu1AVhGdGOoEqsSAhd2W6t&t=221.

Gyldig poeng @U08JKUHA9! Så livekoding er en forutsetning, men ikke tilstrekkelig alene.

@teodorlu Ja, den fra DHH er vel en av de mest kjente live-coding sessions. Jeg tenker egentlig at det er lett å forbedre 'live-coding/demo vennlighet' via å legge til kompleksitet. Et parr andre eksempler hvor dette skjedde (i min mening): • react med JSX (i stedet for vanlig js - React.DOM, eller andre js teknikker). • GraphQL med GraphQL query språket (i stedet for vanlig JSON).

Jeg har live-koda med React.DOM uten problemer!

Men ja, ser poenget ditt. Min tanke var først og fremst at dersom det å live-kode noe blir for mye stuk og styr, så er det et signal om det du driver med er stukete (feks Java, innfløkte rammeverk, osv)

Ja. Så det spørs jo på audience om det er en forbedring eller ikke, men de fleste foretrekker vel JSX selv om det er dumt.

Jeg har aldri forstått apellen til JSX

hvordan ville React i JS sett ut om man ikke hadde JSX egentlig? Jeg har blitt så vant til JSX i JS/TS at jeg ikke tenker over det noe særlig

Et lite eksempel:

...
render: function () {
      return d.input({
        className: "noselect",
        ref: "field",
        type: "checkbox",
        onChange: this.onChange,
        checked: this.state.checked,
        disabled: this.props.disabled,
        onKeyUp: this.onKeyEvent,
        style: { cursor: this.props.disabled ? "not-allowed" : "pointer" },
      });
    }
...

var h = require('react-hyperscript');
var React = require('react');

var AnotherComponent = require('./another-component');

module.exports = React.createClass({
  render: function render() {
    return (
      h('div.example', [
        h('h1#heading', 'This is hyperscript'),
        h('h2', 'creating React.js markup'),
        h(AnotherComponent, {foo: 'bar'}, [
          h('li', [
            h('a', {href: ''}, 'One list item')
          ]),
          h('li', 'Another list item')
        ])
      ])
    );
  }
});

At noen foretrekker JSX-rælet fremfor det første eksempelet her er helt 🤯 for meg

Jeg tror/mener å ha hørt at dette er grunnen til at Sets i JS ikke har map/filter/reduce.

vil tro at du sannsynligvis ikke vil gjøre [lines], men bare lines på siste linje

i og med at lines er i flertall, så antar jeg at det er en seq med strings (en string per linje), men så wrapper du den i en vector, så da blir det en nøsta liste plutselig

aka bør ikke denne funke fint: (write-to-file "test.txt" "Some file content.")

men den bør snus om på så dette funker fint: (write-to-file "test.txt" ["Some file content." "Another line"])

Aha, ja, det funket fint med test vector av strings! Mange takk. Men det funker ikke med output av find-in-files, som er en liste av maps:

(defn find-in-file [file-path pattern]
  (->> file-path
       (file/read-all-lines)
       (map-indexed #(when (str/includes? %2 pattern)
                       {:directory (str (file/parent file-path))
                        :filename (file/file-name file-path)
                        :pattern pattern
                        :line (inc %1)
                        :column (inc (.indexOf %2 pattern))}))
       (filter identity)))

({:filename "A.csproj",
  :pattern "netcoreapp3.1",
  :line 4,
  :column 22}
 {:filename "B.csproj",
  :pattern "netcoreapp3.1",
  :line 4,
  :column 22}
 {:filename "B.csproj",
  :pattern "netcoreapp3.1",
  :line 4,
  :column 22}
 ...)

Er det "best practice" å konvertere den først til et format som babashka.fs/write-lines liker?

vil tippe det - fint å ha en write-to-file som kan ta imot hva som helst, og ikke bare den map-strukturen der

(->> (find-in-files ...)
     (map str)
     (write-to-file "test.txt")

Men er det lurest å konvertere parameteret inni selve write-to-file funksjonen, eller på utsiden før en kaller write-to-file? :thinking_face:

Aha! Er det ikke værre en å bruke map sånn, ja!

Ja, se der! Det gjorde jo susen!

kunne også vurdert å endre write-to-file sånn at den med tre args tar [filename path lines]

altså lines til slutt

generelt er det greit å ha ting som tar lister med lista som siste argument, så det passer inn i threading macro

altså:

(->> (find-in-files ...)
     (map str)
     (write-to-file "test.txt" "/this/folder")

Åja, godt poeng!

Tusen takk for hjelpen, @U0MKRS1FX! Da lærte jeg noen nyttige ting i dag også 🙂 Scriptet begynner å ta form nå: https://github.com/leifericf/leifs-utils/blob/main/src/leifs_utils/git.clj Men jeg må rydde opp en del. Det er masse i git.clj som ikke har noe med Git å gjøre 😅 #lazyboy

Tror jeg skal lage mine egne fs og sh moduler.

jeg ble inspirert på Clojure/west for mange herrens år siden, og tar kontroll på kaoset ved å ha et namespace som rett og slett heter homeless. Det oppleves som mere praktisk å være ærlig på at man ikke klarer å strukturere alt riktig, enn å prøve å få alt til å passe inn på “riktig” sted. Tror @U07FCNURX ofte har det namespacet og 🙂

https://github.com/kodemaker/kodemaker.no/blob/09cc161eea7eebb40d995ad5dd474cdb7db79fd5/src/kodemaker_no/homeless.clj 😄

God idé, det! I podkasten "Functional Design in Clojure" prater karene on "fiddles." Men jeg har ikke prøvd det enda. https://clojuredesign.club/episode/014-fiddle-with-the-repl/

umiddelbar første tanke er at navnet “fiddles” indikerer for meg at man tror at det noen gang kommer til å ryddes opp og at dette var en midlertidig plassering. Men noen ting er jo bare permanent hjemløse 🙂

I podkasten prater de om at "fiddles" på en måte er som "notebooks" som bør sjekkes inn i repo ved siden av koden og fungere som eksempler på hvordan funksjoner er skal brukes. Nesten som "levende dokumentasjon" som man skriver mens man utvikler og eksperimenterer.

ah, sånn sett ja. Høres litt ut som sånn flere bruker comment-blokker i koden, som er lette å kjøre i REPL osv

Jepp! Som en stor comment-blokk på en måte.

eksempel fra jobb

Basically bare for å flytte comment-blokker ut av selve koden sånn at det ikke blir så mye clutter der.

kult egentlig, litt som devcards for ikke-frontend-kode

Ja, jeg synes det var en artig idé!

alt dette blir jo fort veldig nære å være en automatisk test, men

Ja, det er sant. Men automatisk testing viser vel mest hvordan hver enkelt funksjon fungerer, og ikke så mye hvordan man kombinerer dem for å gjøre mer sofistikerte ting. "Fiddles" idéen er på en måte en slags "oppskriftsbok," som også skal illustrere måten utvikleren tenkte på, og hvordan koden har endret seg over tid.

I podkasten prater de om hvordan nye utviklere bruker dem for å lære seg kodebasen.

spennende!

dataene “hvilken kode er viktigst og hvordan brukes den i praksis” er noe et git-repo er dårlig til å svare på

comment-blokk i slutten av fila 👍

ser ingen grunn til å rydde det bort

jeg ville forøvrig hatt en fn ala:

(write-to-file full-path-to-file content)

Lol, kanskje jeg bare kunne brukt clojure.core/spit istedenfor å skrive min egen funksjon til å begynne med 😂

den tar vel ikke linje-etter-linje da, hilsen August “The Premature Optimizer” Lilleaas

Åja, sant, hmmm.

Og jeg er ikke sikker på om den er tilgjengelig i Babashka heller, det må jeg sjekke.

Joda, den er der!

ah, nemlig. Babashka er litt sånn “cljc-modus”, altså du gjør ikke JVM-ting der naturlig nok?

Nope, Babashka kjører jo på GraalVM og har ikke alt som JVM Clojure har. Men den er overraskende mye.

ah ok, så da er det en “JVM” der med standardlibbet osv

Jeg tror Babashka har "nesten alt" fra clojure.core + en del libs som borkdude og andre har implementert støtte for.

Her er info: https://book.babashka.org/#libraries

@U04V5VAUN Slik omtrent? 🙂 Se spit-file nedenfor.

(defn get-filename-prefix []
  (.format (java.time.ZonedDateTime/now)
           (java.time.format.DateTimeFormatter/ofPattern "yyyyMMdd-HHmmss")))

(defn write-to-file
  ([filename lines]
   (let [default-path (str (file/home) (:local/output-dir settings))]
     (write-to-file default-path filename lines)))

  ([path filename lines]
   (let [prefixed-filename (format "%s_%s" (get-filename-prefix) filename)]
     (if-not (file/exists? path) (file/create-dirs path) nil)
     (file/write-lines (str path "/" prefixed-filename) lines))))

(defn spit-file [path content]
  (write-to-file (file/parent path) (file/file-name path) content))

(comment
  (write-to-file "test.txt" ["This is" "just a" "test"])

  (write-to-file "/Users/leif/tmp/test" "test.txt" ["This is" "just a" "test"])

  (spit-file "/Users/leif/tmp/test2/test.txt" ["This is" "just a" "test"])

  (->> (find-in-files ["csproj"] "netcoreapp3.1")
       (map str)
       (write-to-file "test.txt")))

Skriv en test for get-filename-prefix

Jeg ville kanskje latt write-to-file (eller spit) bare ta en text blob som den skreve til filystemet. Noen(TM) over kunne ha ansvaret for transformasjonen fra data til text.

Har planer om å skrive en del tester, ja! Har ikke satt meg inn i hvordan det gjøres i Clojure (og Babashka) enda.

@U01PE7630AC det om å skrive test for akkurat den funksjonen er en invitasjon til en diskusjon.

Jeg var for noob til å forstå det 😅

En funksjon som ikke tar argumenter er enten side-effektende, eller så er det en konstant.

En sideeffektende funksjon er vanskelig å skrive unittest for.

De fleste av funksjonene mine har vel sideeffekter i og med at de direkte eller indirekte eksekverer shell commands, leser og skriver filer, osv.?

går alltids an å ha en fixtures-mappe med noen ekte filer i som man kan kjøre testene mot på en stabil måte

https://github.com/magnars/test-with-files

så kan man kanskje skrive til en tempfile elns så den blir rydda opp av OS

Ja, det var det jeg tenkte også, @U0MKRS1FX — Bare lage en mappe med en masse filer i for å teste.

haha lurt, Optimus mm gjør jo en del fil-greier som er greit å få testet!

Haha! Takk, @U07FCNURX — Så klart du har et bibliotek for det også 🙂 Nice. Vil det funke i Babashka, tro? :thinking_face:

Aner ikke. Det bruker java.nio

Da tipper jeg det funker, fordi det gjør babashk.fs også.

Men trikset er jo å skrive kode på en slik måte at mesteparten er pure, og bare noe er sideffecting

FC/IS 😻

noen må lage en mere catchy forkortelse

Ja, absolutt. Jeg har mye å lære der.

Vanlig kode skriver man ofte som:

er utvilsomt en trade-off der da, for relativt små greier så blir det jo fort flere ting å ha i hodet om man skal abstrahere bort I/O

(defn foo [whatever]
  (let [a ;; some calculation
        b ;; some calculation
        c ;; some calculation]
   (sideffect a b c))

(defn calculate-it [whatever]
  {:a ...
   :b ..
   :c ..})

(->> whatever calculate-it sideffect)

og nå er calculate-it ren og superenkel å unit-teste

foonctional core

mens for å teste foo må man ty til mocking og annen styggedom.

FC/IS er fint og flott, men her har @U01PE7630AC virkelig starta i side-effektenes land. Shell script er nødvendigvis mye side-effekter, og når det er mer side-effekter enn forretningslogikk så er det ofte litt vanskelig å treffe godt med FC/IS

Haha, godt å høre, @christian767. Jeg har sittet og revet meg litt i håret og tenkt: "Hvordan i alle dager skal jeg få bukt med disse sideeffektene når jeg driver med shell scripting? Er jeg helt idiot?"

businesslogikken til et shellscript er jo på en måte selve I/O-en

Enig, men samtidig: Dra likevel ut logikken fra sideeffektene der du kan. Ikke klabb logikk inn sammen med skrivingen bare fordi du har "gitt opp".

Hvis du skal filtrere og rødde litt i dataene før de skrives, så gjør det i en egen funksjon som kan testes for seg.

For min del er det ikke at jeg har "gitt opp" men at jeg egentlig ikke forstår meg på alt dette enda. Er ganske grønn. Men jeg føler at jeg lære ganske mye hver dag nå egentlig, med hjelp fra dere og i andre kanaler her på Slack.

Jeg vil bare gi en liten trøst 🙂 Shell script er ikke der man får til FC/IS best, så ikke bli demotivert og gi opp. Gjør som @U07FCNURX foreslår, men også slå deg til ro med at det er mye side-effekter i et shell-script.

Men tilbake til mitt lille poeng med den lille funksjonen.

(defn get-filename-prefix []
  (.format (java.time.ZonedDateTime/now)
           (java.time.format.DateTimeFormatter/ofPattern "yyyyMMdd-HHmmss")))

(defn get-filename-prefix [ts]
  (.format ts
           (java.time.format.DateTimeFormatter/ofPattern "yyyyMMdd-HHmmss")))

å sende “now” som argument ftw

Ja, det er et godt tips. Du vil aldri kalle now inne i random funksjoner - bare helt ytterst i systemet ditt

Takk for det, @christian767! Jeg har også observert at teamet sideeffekter er en gjenganger i #babashka, og der klanger et lignende sentiment.

Er det "lov" å "skjule" java.time.ZonedDateTime/now bak en egen liten wrapper-funksjon? Typ:

(defn get-current-time []
  (java.time.ZonedDateTime/now))

(defn get-filename-prefix [timestamp]
  (.format timestamp (java.time.format.DateTimeFormatter/ofPattern "yyyyMMdd-HHmmss")))

(get-filename-prefix (get-current-time)) ; => "20230627-125216"

kan kalles som (ZonedDateTime/now) og hvis den er importert med (:import [java.time ZonedDateTime])

Jeg trodde ikke egentlig Java time drev med defaults, men dette ser mistenkelig ut som om du antar systemets locale? :thinking_face:

har vel strengt tatt ikke noe å si hvilken tidssone du har i en ZonedDateTime, sånn rent funksjonelt/logisk

(defn get-current-time []
  (java.time.ZonedDateTime/now))

@U0MKRS1FX nei, men det spiller en rolle i hvilken tidssone du ber om now

hmmmm :thinking_face: Om du får 12:57 i GMT+2 eller 10:57 i GMT+0 har vel ingenting å si senere i koden

altså, du ber om “now” når koden kjører, og hvilken tidssone den er representert i blir vel hipp som happ

det er kanskje det?

Hvorfor ikke bare bruke LocalDateTime/now?

da er den vel ikke et timestamp lengere, men en referanse til hva som stod på klokka når/der koden kjørte

Så for meg ut som om hva som står på klokka er det den brukes til

ah, jeg var i generisk si-smarte-ting-om-tidssoner-modus, ikke hva-trenger-egentlig-koden-modus 😄

enig der ja, gir mening å bruke LocalDateTime når man skal skrive filer med timestamp til disk der og da

(:import [java.time ZonedDateTime]) ser ikke ut til å fungere i Babashka.

jøss

prøv (:import java.time.ZonedDateTime)

Jeg gjorde det slik:

(:require [babashka.fs :as file]
            [babashka.process :as process]
            [cheshire.core :as json]
            [clojure.edn :as edn]
            [clojure.string :as str]
            [java.time.ZonedDateTime :as datetime])

; java.lang.Exception: Could not find namespace: java.time.ZonedDateTime.

:import, ikke :require

(ns my.lol
  (:require [babashka.fs :as file]
            [babashka.process :as process]
            [cheshire.core :as json]
            [clojure.edn :as edn]
            [clojure.string :as str])
  (:import [java.time ZonedDateTime]))

Kan du ha :as på imports?

ah, nei

sorry

Ble litt for mye Møllers copy-paste

Det ser ut som den forventer navn på klasser også, så jeg måtte gjøre:

(ns leifs-utils.git
  (:require [babashka.fs :as file]
            [babashka.process :as process]
            [cheshire.core :as json]
            [clojure.edn :as edn]
            [clojure.string :as str])
  (:import [java.time.ZonedDateTime now]))

Eller, nei…

Import kan enten se sånn ut: (:import [java.time ZonedDateTime]) eller sånn: (:import java.time.ZonedDateTime)

Eneste grunn til å bruke førstnevnte er hvis du vil importere flere klasser fra samme pakke

Begge resulterer i at ZonedDateTime kan brukes ukvalifisert i namespacet

Ahaaa. Fancy.

Ja, kanskje til og med unødvendig fancy 😅

det er overraskende mye syntaks i Clojure til å være et språk uten syntaks 😬

Eg har brukt

(defn today-yyyy-MM-dd-utc []
  (.format (ZonedDateTime/now (ZoneId/of "UTC")) (DateTimeFormatter/ofPattern "yyyy-MM-dd")))

(with-redefs [mitt-ns/today-yyyy-MM-dd-utc (fn [& _args] "2000-01-01")]
...

Jeg synes jo da at with-redefs er en code-smell som du hadde sluppet unna dersom du hadde sendt now som en parameter.

Og for å kaste stein i glasshus. I vår eminent navngitte parameter ctx som holder diverse informasjon vedrørende gjeldene request, så finnes også :user-time . Denne blir satt i det requesten mottas.

Så ingen funksjoner som mottar en ctx trenger å side-effecte for å finne tiden.

Vi gjør det på samme vis

Einig i at with-redefs er (litt) smelly... Samstundes: Dømet over er frå eit lite bibliotek. Eg tenker (av og til?) at det vert tungt å sende "ned" 'now' overalt, og ikkje alle bibliotek støtter det heller naturlegvis. (Men ja jo det er naturlegvis betre å ha det som ein (optional) parameter/input) Eg vil ikkje kalle å henta tida for ein side-effect, heller ein "world"/external dependency

Da kaller vi det side-effect på bokmål og “world”/external dependency på nynorsk?

/me hiding

høhø, janei 😁 Godt spørsmål kva ein skal kalle det på norsk. Google seier biverknad (bivirkning på bokmål). Eg kalte det https://github.com/ivarref/yoltq/blob/main/src/com/github/ivarref/yoltq/ext_sys.clj i yoltq (eige namespace)

Bivirkning er jo konge!

Ja, det er bra for ting som endrar ting (på disk f.eks.). Ting som berre "les" verdiar frå systemet (klokke f.eks.), meiner eg kan (burde?) heita noko anna

“denne funksjonen har bivirkninger”, da skjønner man jo at det er noe galt på ferde.