clojure-norway 2023-08-30

Kent Beck og en til har skrevet godt om Mckinsey: https://tidyfirst.substack.com/p/measuring-developer-productivity

👍 4

ah, kult, de har faktisk gjort disse tingene > At Facebook we [Kent here] instituted the sorts of surveys McKinsey recommends. That was good for about a year

cjohansen07:08:50

Jeg klarte ikke å sette ord på det like godt som Kent Beck og kompani - men nå vet jeg at det jeg reagerte på var at nesten alle målene handler om “effort”. Jeg har nok erfaring til å vite at det er en dårlig metrikk, selvom jeg ikke har prøvd det på samme skala som Kent Beck i Facebook.

augustl07:08:45

altså “hvor mye tid har blitt lagt inn i diverse greier”, mot for å f.eks måle “hvor bra er softwaren” osv?

cjohansen07:08:59

Feks

cjohansen07:08:28

Retningen målingene tok hos Facebook er også relativt forutsigbare

leifericf12:08:22

Jeg synes det er interessant hvordan smarte folk kan finne på så dumme ting. Ikke at jeg er et prakteksemplar selv heller. Jeg finner også på dumme ting stadig vekk. Så jeg bør kanskje inkludere meg selv i min egen betraktning 😅 Kanskje jeg faktisk er et prakteksemplar allikevel i den forstand, haha.

leifericf12:08:41

For å bli så dum må man være ganske smart 😂

cjohansen05:08:59

God morgen!

teodorlu06:08:11

Morn!

leifericf07:08:06

God morgen alle sammen!

augustl07:08:21

god morgen, far og mor!

leifericf07:08:07

Etter diskusjonene om kodekvalitet og kompleksitet i går, kom jeg til å tenke på en ting: Stephen Wolfram har et ganske ambisiøst prosjekt på gang. Han følger i Einstein sine fotspor for å finne "the fundamental theory of physics" (det finnes mer info på https://www.wolframphysics.org). Han har også gjort https://www.youtube.com/watch?v=4-SGpEInX_c om det som går mer i dybden. Som en del av det prosjektet har han funnet på en https://writings.stephenwolfram.com/2021/09/charting-a-course-for-complexity-metamodeling-ruliology-and-more/. Når jeg hørte på podkasten første gang tenkte jeg, "dette lar seg kanskje implementere for å måle kompleksiteten i kildekode." Men så la jeg idéen tilbake i roteskuffen og glemte det, frem til diskusjonen i går. Ref. det med "afferens" og "efferens" som @msolli nevnte. Det kan tenkes at noen av dere vil synes dette er interessant også. Jeg er litt usikker på om Wolfram har blitt gal eller om han er et geni. Det vil vel tiden vise 😅

👍 2

augustl07:08:30

spennende, kanskje “kompleksitets-måling” kan utvikle seg til å bli et helt eget felt, på et eller annet vis

leifericf07:08:16

Ja, det tror jeg! Jeg klarte ikke umiddelbart og finne tilbake til den delen av podkasten som var relevant for temaet, men jeg skal se om jeg finner det senere. Det var enklere å følge idéen når de pratet om det, enn i tekstene som Wolfram og teamet hans har publisert.

leifericf07:08:27

Wolfram har jo dedikert store deler av livet sitt til å definere og måle kompleksitet. Det er et sentralt tema i nesten alle artiklene han har publisert og bøkene han har skrevet. Enkelte deler er veldig filosofisk, men han er mye mer praktisk enn de fleste andre som skriver om teamet i den forstand at modellene hans kan implementeres og testes, om ikke nå i fremtiden når vi har bedre teknologi.

leifericf07:08:44

Pluss at https://www.wolframphysics.org/visual-summary/dark/ er bare helt nydelig :star-struck:

😍 2

augustl10:08:34

tanke: flere webapper bør ta i bruk localstorage til viktige subsett av tilstanden sin, og ha et aktivt forhold til når man sletter ting derfra. Alt for lett å putte viktig data i “RAM” og så kom man borti back-knappen elns og mista kritisk data

👍 2

augustl13:08:35

ny tanke (I’m on a roll): det vanskeligste med feilmeldinger i GUI er å håndtere “oh crap her er det en feilmelding i dataene men ingen av GUI-komponentene viser den”

cjohansen13:08:28

Enda en ting som er lettere å løse med sentralisert data og enveis dataflyt. Bygg på et sentralisert feilhåndteringssystem: trenger ikke å ha feilhåndtering mange steder, mer konsistent feilhåndtering, slipper feil-oppå-feil, lettere å sørge for at enhver feil hvor som helst i dataene alltid vises ++

augustl13:08:15

ble sittende å tenke på det her nå ja. Å få til dette samtidig som man koder rendring er helt bananas umulig å få til fint. Men om du bare kan reduce deg over noen feil-data når man bygger opp GUI-data, og så se etterpå hva man står igjen med i et map som har blitt dissoc-et av, så har man jo en fin generisk løsning på det

cjohansen13:08:47

Det er så mange ting som blir lettere å få til med sentralisert data og enveis dataflyt ❤️

slipset13:08:35

A propos feilmeldinger: Robotstøvsugeren sa at den ikke kunne finne dock’en sin og ba meg pusse den påstått skitne “la meg se dock’en min sensoren”.

cjohansen13:08:08

localStorage også, som du nevnte over 😄 Appen vår på Fortum hadde syncet det globale atomet til localStorage på hver swap (med debounce). Problem solved

augustl13:08:10

fant igjen denne koden her jeg skrev for et års tid siden. Dette funker jo greit nok, men det er ganske verbost (og på en måte imperativt?) og så brakk det nå som jeg conditionally skal skjule et felt i rendringen etterpå… :S

slipset13:08:15

Det som var feil var at robotstøvsugeren hadde tatt med seg dock’en ut på tur og revet ut støpselet.

😂 10

cjohansen13:08:29

Herlig @slipset

cjohansen13:08:07

“feilmeldinger-by-field” 😅 😅 😰

😅 4

cjohansen13:08:31

Den koden der ønsker seg en reduce over [:besetningstype :fastavtale ,,,] tror jeg 🙂

cjohansen14:08:51

Etter de fem atomene å dømme så er dere et stykke fra én global data store i dette prosjektet @augustl?