Fork me on GitHub
#clojure-norway
<
2022-08-26
>
slipset05:08:37

Hvilken dag er det i dag? hvilken dag er det idag? Er det zombie-dag? Ja!

😍 1
🧟 4
Christian Johansen06:08:59

Braaaaaaains morgen!

magnars07:08:24

God morgen, ja 😊 Her er Episode 26: Max Payne https://www.zombieclj.no/s02e26.html

Christian Johansen07:08:46

Brå slutt på jula

magnars07:08:08

Som seg hør og bør. Andre juledag er det på hue og rævva ut med juletre og nisser. 😅

oddsor09:08:15

Juletreet skal stå til langt uti januar! tree-shake

magnars09:08:51

For å være ærlig så har vi laaang jul her i huset også, men det passet ikke så bra med narrativet her. 😅

oddsor09:08:19

helt fair, av og til må realiteten tilpasse seg narrativet :thumbsup:

😁 1
magnars07:08:14

og inn med klassiske finske skytespill

😂 1
slipset08:08:27

I dagens episode hadde det vel vært fint med et typesystem, idet health gikk fra å være int til {:current int, :max int}?

magnars08:08:50

tja, hvor mange minutter hadde vi spart på det? hvor mange minutter tapt?

slipset09:08:30

Uansett, poenget med å fordumme klienten er jo helt konge. Isteden for at klienten må være smart (og deale med tall og greier), så endte dere med at klienten bare looper over noe data, og ferdig.

magnars09:08:21

veldig deilig konsept!

Christian Johansen09:08:16

Veldig fint når man klarer å finne en så ren arbeidsfordeling. Serveren er smart, klienten er dum. Når det blir “kode” på klienten så er noe gæernt.

slipset10:08:08

Det er forøvrig en interresant påstand. Hos oss er vi helt klart delt i frontend og backend utviklere, selvom noen av oss er full stack. Historisk så er frontenden skrevet med Backbone, hvilket betyr at backenden startet som en relativt dum database med et forferdelig spørrespråk, REST. Vi ser at vi “hele tiden” debaterer om hvor mye logikk som skal ligge på frontend vs backend, hvor skreddersydde endepunktene skal være for de operasjoner som gjøres, eks. PUT /api/user vs POST /api/user/reset-password

slipset10:08:39

Det er også et spm om hvem som skal sørge for denormalisering av data, om det gjøres på frontend eller backend.

Christian Johansen10:08:05

Våger meg på en påstand til da: Det er lettere å håndheve en god arbeidsfordeling mellom frontend og backend når de samme folka har tilgang på begge steder. Kjør debatt!

Christian Johansen10:08:40

Jeg tenker at det er lettere å ta gode valg på kodens vegne om det ikke også legger føringer for hvem som må gjøre jobben (og hvorvidt de er tilgjengelige, osv)

🎯 2
magnars10:08:45

Velkommen til Conway's law 🙂

😄 2
slipset10:08:16

Allé har tilgang, men ikke alle har viljen.

slipset10:08:05

Og, vi har videre forsterket Conway ved å ha forskjellige språk foran og bak.

Christian Johansen10:08:29

Et frontend-team og et backend-team skaper en illusjon om et skarpt skille, som i praksis er en stor gråsone. Det er noen ting som helt klart er “ren frontend”: designrammeverk, tilstandsløse komponenter, og lignende. Og så er det “ren backend”: persistering, integrasjoner osv. Men dataflyt foregår på begge sider av skillelinja. Det er lettere å lage god dataflyt om man ser på helheten, heller enn halve jobben på hver side av en mer eller mindre arbitrær grense.

Christian Johansen10:08:04

Jeg syns ihvertfall at det er mye morsommere å jobbe i web-prosjekter som ikke har denne delingen, for man kan se løsningen mer under ett, og jeg opplever at mye av tiden min brukes “i midten” der, hvor ting kan være både frontend og backend, men hvor kontekst, gjeldende arkitektur, eksterne krav osv tipper balansen den ene veien eller andre.

🎯 4
slipset10:08:37

Ikke uenig.

hkjels10:08:30

Utrolig kjedelig å vente på en bestilling som aldri fullføres. I mine øyne så er fordelingen back-end/front-end helt meningsløs når man har Clojure som kan leve på begge sider

hkjels10:08:24

er man bundet av legacy og andre språk, så har jeg noe mer forståelse

msolli11:08:46

For å sette det på spissen: Tenk om backend-teamet måtte koordinere med et database-team for å få skrevet spørringer. Det er jo ulike språk! (SQL, Datalog osv.) Og koden kjører på en annen maskin! På en helt annet “stack”! Det blir jo absurd. Men det er den slags tankegang som synes å styre den utbredte oppdelingen i frontend og backend. Det er et skille som er trukket opp tvers over HTTP-protokollen og på tvers av hensynet til brukerne (de bryr seg ikke nødvendigvis om hvor koden kjører og hvilket språk den er skrevet i).

msolli11:08:53

Noen steder med frontend-team har jeg sett at de med hell har tatt kontroll over “sin” del av backenden ved å lage en egen web-backend (BFF - Backend For Frontend). Denne kan ha ansvar for web-greier, autentisering og den slags, og delegere til den “ekte” backenden for forretningslogikk.

augustl11:08:36

var på et prosjekt hvor vi hadde teams for frontend/backend separert. Men det handlet mere om hvem som var i møter og hvem som var pådrivere osv. Når vi på frontend/app trengte noe nytt i backend, lagde vi det sjæl

Christian Johansen12:08:14

@msolli BFF åpner for å ta bedre avgjørelser for en større del av kodebasen, men i byttet mot enda en HTTP-vegg 😅 Det blir bedre, men fortsatt vil det være ting som må “bestilles”, og Conway lever videre

msolli13:08:28

Absolutt - det var mer en observasjon jeg har gjort meg for noe som har fungert når man ikke kan, i hvert fall på kort sikt, ta kontroll over hele “verdikjeden”. Og så kommer det jo an på hvor ofte ting endrer seg i forretningen. Jo flere endringer, jo viktigere at ett team har kontroll på alt sammen.

Christian Johansen13:08:18

Og det er helt klart bedre enn et helt strikt skille

restenb14:08:56

jeg har jobbet i systemer med mye fysikk-basert forretningslogikk som jeg ikke nødvendigvis skjønner eller bryr meg så mye om. denne foregikk på en annen server og/eller prosess enn min web-backend, hvor jeg hadde kontroll på stacken frem til og med grensesnittet imot "alle de der ligningene", som noen andre jobbet med. det var egentlig fullstendig problemfritt.

☝️ 1
👍 1
augustl14:08:29

noen ganger jobber Conway’s lov til vår fordel 🙂

restenb14:08:16

hehe, gitt at kommunikasjonen mellom partene er god nok så er det Conway's lov i praksis det. når jeg tenker tilbake, hadde vi god kommunikasjon. selv om "fysikerne" etterhvert ble mer programmeringskyndige og klødde seg inn i kodebasene jeg satt med, gikk det også greit for det meste.

augustl14:08:32

godt poeng! Conway’s lov adresserer jo spesifikt kommunikasjonshierarkiet, ikke beslutningshierarkiet

teodorlu16:08:58

Hvis kompetanseskillet "noen kan frontend, andre kan backend" er problematisk, finnes det bedre måter å dele inn kompetanse? Som ikke antar at man trenger å kunne alt? Jeg har sett inndeling etter backend / frontend og inndeling etter "slice av produktet", men jeg har ikke sett noen andre måter å gjøre det på.

isak16:08:55

Jeg forstår egentlig ikke den tankegangen at man jobber på backend og ikke gidder å lære seg litt frontend. Da håper jeg de jobber med noe ekstremt kompleks, som et operativ system, relational database, osv. Men hvis man har ekstremt god kommunikasjon og sammarbeid med noen som kan det går det sikkert fint. Det blir kanskje også litt mere gøy enn å gjøre hele featuren selv.