Snedig løsning! https://clojurians.slack.com/archives/C03S1KBA2/p1719301400147549?thread_ts=1719296438.962579&cid=C03S1KBA2 Ikke farbart for et bibliotek, men noe man kanskje kan koste på seg i en appkodebase

haha, moro! Får litt vibes av monkey patching i ruby

Absolutt, sa akkurat det samme til Magnar. Dersom Powerpack gjorde dette hadde jeg vært igang med å bli statiske sites sin Rails 😂

Haskellerene gnir seg sikkert godt i hendene nå altså, der man får en kompileringsfeil og aldri ville truffet på dette problemet 😈

Jeg har hørt at Haskell-kode heller ikke kompilerer når programmereren har misforstått oppgaven

man må bare alltid ha en mere senior programmerer som har fått inn business-regler i typesystemet

Dette er to ulike regulære uttrykk som gir opphav til det samme regulære språket. Det virker helt OK å definere likhet over uttrykkene, snarere enn språkene de uttrykker.

Ganske sikker på at dette ikke stemmer! Jeg så noen andre skrive det i en av trådene som diskuterte dette. Regulære uttrykk konverteres som regel til tilstandsmaskiner. Tilstandsmaskiner kan konstrueres på en måte som lar dem minimeres, og den minimale tilstandsmaskinen er unik (opp til navngivning av tilstandene). Altså uttrykker to regulære uttrykk det samme regulære språket hvis og bare hvis de gir opphav til den samme minimerte tilstandsmaskinen! https://en.wikipedia.org/wiki/Thompson%27s_construction

Å minimere tilstandsmaskinen er NP-hardt da, så det er nok ikke en god idé å sette i gang den prosessen der for en likhetssjekk 😅

Det du nevner var det som ble sagt i issuen, men det føler jeg er en unødvendig feature creep. Det er nyttig å vite at to dataliteraler er like, uten å kunne si noe om hele settet av regexer som matcher den samme strengen.

Jeg tror jeg er enig med deg i det.

Takk for inspirerende morgenlesning! I forlengelse av temaet du trekker fram vil jeg også anbefale lydboken 'https://www.goodreads.com/book/show/172800.Beyond_the_Goal' av doktor Goldratt. Innsiktsfullt i foredragsformat, og peker bl.a. på et relatert problem til det du peker på: 'Best practice' utdateres. Og når vi gjør (teknologiske) forbedringer og forandringer som fjerner begrensninger og hindringer, forandres reglene for hva vi kan gjøre og hvordan. Men alt for ofte lar vi være å fjerne de gamle praksisene som fantes for å håndtere de gamle hindringene (som vi nå har fjernet), og vi får i beste fall begrenset gevinst av de nye praksisene vi har innført.

Helt nydelig, innlegget er i aller høyeste grad inspirert av Beyond the Goal 😄

Hahaha, Gene Kim har latt seg inspirere av "Beyond The Goal" også 😄 https://www.goodreads.com/book/show/38714647-beyond-the-phoenix-project?ref=rae_6

Hørte det i etterordet til Phoenix Project som jeg leste på nytt forrige uke 😄

Noen som har sjekka den ut?

Jupp. Jeg likte den veldig godt. Peker egentlig mer mot The DevOps Handbook enn Phoenix Project, IMO. Men den er veldig forskjellig fra Beyond The Goal i innhold og funksjon. Som jeg leste (altså; hørte) den, er BTPP en refleksjon over research og skriving av de to bøkene på den ene siden, og tanker omkring hva man har sett og lært siden på den andre. BTG er slik jeg forsto det opptak av en forelesningsserie Goldratt leste inn for å spre tenkningen som ligger bak ToC og de logiske tankeprosessene.

Ikke til forkleinelse for noen av dem, iofs.

> Noen som har sjekka den ut? > Jeg har ikke lest den selv (ennå)

Dan North som ikke heter bare fet lenger, ga en talk for noen år siden om Beyond The Goal. https://youtu.be/hZFShSjAhlQ?feature=shared Videre har vi «de fire spørsmålene» https://medium.com/benjamin-mosior/the-four-questions-15f93a16e41, og essensen i Beyond the Goal er at vi som regel glemmer å stille oss 3 & 4

For oss litt eldre utviklere, som husker en verden før CruiseControl/Jenkins/Whatnot, tenk på de fire spørsmålene i forbindelse med innførselen av teknologien «CI»

Og, en annen øvelse vil være å tenke på de fire spørsmålene i forbindelse med innførselen av eksempelvis AWS.

Hvis vi bare flytter eksisterende on-prem infra ut i skyen, men ikke endrer måten vi jobber på ut fra de fordelene som skyen gir, da har vi ikke svart på spørsmål tre og fire, og vi mister de store fordelene av å flytte til skyen.

> Dan North som ikke heter bare fet lenger Error: Failed to parse. Plz explain.

Sorry. Dan North heter nå noe mer enn Dan North, jeg bare husker ikke hva…

aha, sånn ja 😄

Ja, han tok navnet til kona når han gifta seg tror jeg

Jeg fryktet at Dan North hadde blitt canceled 😅

Nei, hvis han blir kansellert, er det mye som er rart.

Føler egentlig at vi burde hatt denne diskusjonen på LinkedIn :) Mye større rom for thoughtleadership der :)

Enig, jeg har posta på linkedin også, bare å gå dit å gjenta svarene!

Sliiiiiiitsomt!

Veldig interessant at så mange her inne har lest disse tingene.

Jeg har nylig stilt spørsmålet i et par andre settinger og fått svært få hender i været 🙂

@slipset opp til deg, du er kanskje ikke så investert i at Clojure-miljøet skal være senter for interessante faglige diskusjoner på LinkedIn?

Sånn! Da har jeg kopiert og startet thoughtleadership på LinkedIn

Da beklager jeg trollinga mi 😄

Husker forøvrig ikke når jeg leste The Goal for første gang, men den har vært veldig viktig for meg.

Jeg leste den for første gang for en måned siden og ble feid av banen. For en fantastisk bok. Hoppa rett videre på Beyond the Goal, og ble inspirert til å lese Phoenix Project på nytt. Holder nå på med andre runde av Unicorn project 😄

Hvordan hørte dere først om The Goal, da?

Hvis man forstår utilization va throughput, begynner å se etter flaskehalser og skjønner at det ikke er noe poeng i å optimalisere oppstrøms for flaskehalsen, ja da har man jaggu skjønt en del.

@U9CU2PQPM fra min favorittkollega ever Henning Spjelkavik.

The Goal nevnes mange ganger gjennom The Phoenix Project. Inspirasjonen er ikke forsøkt gjemt 😊

Forøvrig går veien fort videre til køteori og sånt. Verdens mest søvndyssende foreleser, Don Reinertsen har noen kule talks rundt dette og annet fra Yow 2015.

https://youtu.be/H5FZEciOgI8?feature=shared

Basically så sier vel Reinertsen at dersom du har 100% utilisasjon, så har du ingen mulighet til å takle uforutsette hendelser.

Det blir litt mye skirveleifer her. Skylder på ferie og Apple.

Jeg liker også bildet med at en vei som har 100% utnyttelse effektivt har gjennomsnittshastighet 0.

Dette var spennende! Jeg begynte på the Goal for en uke siden 😄

Jeg tror industrien vår hadde blitt bedre om vi hadde tatt Goldratt og Theory of Constraints seriøst. Jeg har tidligere tenkt mye på å "lage god kode" som "å lage en god teori for problemet som skal løses, og deretter holde koden konsistent med teorien". (se Naur, 1985, https://pages.cs.wisc.edu/~remzi/Naur.pdf) Men Goldratt jobber med et annet problem enn Naur. Naur snakker om hva koden er, Goldratt snakker om prosessen rundt koden over tid. Eller man kan bruke TOC direkte på produkter. Hvem bruker produktet, og til hva. Først da kan man si noe om throughput. Ta med hele fabrikken, og produktene som shoppet heøt ut til kunder, ikke stopp halvveis. Eller ta med endringer i produktet helt ut til at du ser at nye brukere faktisk bruker det som har blitt laget. Operational expense er ganske rett fram - det er fint om det er lite herk å gjøre endringer. Inventory er mer spennende. På fabrikken blir det fullt på gulvet hvis det ligger for mye greier rundt. Når folk er involvert, blir dette mye viktigere. Jeg har kapasitet til å gjøre 1 eller 2 ting selv. Helst 1 - men å ha en liten ting på siden kan noen ganger være fint. Dette er kanskje den viktigste verdien jeg ser med parprogrammering og mob-programmering. Det gjør at flere kan jobbe effektivt på samme ting, så kan man ha mindre work in progress / inventory i teamet som helhet.

> “Alle” var enige om at The Goal beskriver en bedre måte å drive en fabrikk på, men allikevel fant Goldratt 20 år senere at kun 2% av verdens fabrikker hadde implementert idéene hans. Resten gjorde ting på den gamle måten, som så grundig blir plukket fra hverandre i boka. Hvordan kan det ha seg, og hva sier det oss om “best practice”? > Jeg har tenkt litt på ordet "kunnskapsdifferensial". Hva forskjellen på det folk vet/tror er. Finnes igjen både innad i team (noen kan et subsystem, noen kan en teknikk) og i industrien (forskjellig praksis, forskjellig teori). Det vil nødvendigvis være forskjeller på hva folk kan. Det er også ønskelig! Vi vil jo at folk lærer nye ting. Målet er kompetanse, ikke konformitet. Så er spørsmålet hvordan vi tar folk fra ferske til effektive. "vanligste praksis" kan være et steg 1, men jeg håper ikke det blir sluttmålet. Det hadde vært litt synd om man skulle ende opp der. "nå har jeg lært den vanligste måten å gjøre ting på, nå er jeg ferdig". Jeg hadde blitt drittlei hvis det var jobben min!

Gode refleksjoner @teodorlu 👍

Jeg tror vi i IT-bransjen har overstadige mengder av "local optimizations", som det gjøres et stort poeng ut av i The Goal. Og det er bekymringsverdig at mange beveger seg mer i den retningen med stadig mer spesialiserte oppdelinger (hallo, frontend/backend-teams). Det er helt mulig å gjøre en jobb med flere "work centers", men det stiller særlige krav til at noen tenker på flyten gjennom hele systemet, og det tror jeg ofte er mangelvare.

Et poeng Goldratt selv toucher på i Beyond the Goal er at mange unngår å bruke teoriene hans selv etter å ha lært om dem, fordi det går imot folks inuisjon. Dette fenomenet kjenner jeg fra andre arenaer også. Det er feks gjort mye forskning på hvordan man best lærer mekaniske øvelser (sport/idrett, musikkinstrumenter, osv), og der ser man også at de mest effektive metodene er kontraintuitive. Og selv etter å ha lært om dem og erfart effekten selv har folk lett for å falle tilbake på det som føles trygt og godt (men som er beviselig mindre effektivt).

Hva vil du anbefale at man leser? Hvis jeg starter på Beyond The Goal, er det vits i å lese Critical Chain?

Har du lest The Goal @teodorlu?

I høyeste grad. Beyond The Goal er i mine ører en foredragsrekke som gir deg justering av perspektiv; den får deg til å tenke og reflektere riktigere, og hvis jeg husker riktig gir den en forståelse for hvordan man bør bruke de logiske tankeprosessene og tilpasse dem konkrete kontekster. The Goal lærer deg byggestenene i ToC og frister deg med at de logiske tankeprosessene finnes, mens Critical Chain viser deg hvordan ToC kan appliseres på prosjektarbeid.

Jeg ville lest BTG sist. Da får du nok mest utbytte. Men kanhende er det bare fordi det var det jeg selv gjorde. Hvis du velger å gjøre noe annet, er jeg veldig interessert i å høre hva du tror og tenker.

> Har du lest the goal? > Jepp :) likte den veldig godt. Fikk meg til å lese et par andre Goldratt-bøker også, men har ikke lest Beyond The Goal eller Critical Chain.

Critical Chain er en forretningsroman, akkurat som The Goal.

Og en som er lite skånsom i sin kritikk av MBA-studier, om jeg husker riktig.

> Jeg ville lest BTG sist. Da får du nok mest utbytte. Men kanhende er det bare fordi det var det jeg selv gjorde. > Sist som i "etter både The Goal og Critical Chain"?

Goldratt slår meg ikke som en særlig skånsom type 😅

Han snakker selv mye om "Necessary but not sufficient", men den var ikke å finne på Audible. Mange av bøkene hans er gratis på Audible (hvis du har abonnement).

"Waltzing With Bears" av Tom DeMarco er også en god forretningsroman jeg kan anbefale. Han har skrevet mye annet bra for øvrig. Tenker på "Peopleware" og "Slack."

"The Secrets of Consulting" av Gerald M. Weinberg og "Intuition Pumps and Other Tools for Thinking" av Daniel C. Dennett er også fantastiske og morsomme i tillegg. Anbefales.

"Necessary but not sufficient" finnes i Kindle-versjon (i tillegg til FDT).

Dette er dritgøy! Fant ut at jeg faktisk har vært gjennom Critical Chain en gang, jeg bare husket det ikke. Den traff ikke like godt for meg som The Goal. Tror det har med erfaring å gjøre. Jeg har jobbet i byggeprosjekter som har fungert bra, og jeg har ikke sett feilene han beskriver tydelig der. The Goal var mer "hjernevrengende" for meg - utrolig godt utgangspunkt for å forstå kontinuerlige prosesser som skal løse et problem. Jeg fant noe i kapittel 6 i Beyond The Goal som jeg tror jeg er litt uenig i, men det går jeg heller ta tak i senere. Har egentlig startet ferie, og prøver å lage litt plass til å tenke på andre ting enn programmering og clojure.

Beyond the Goal er fra tidlig 2000, så ikke helt sjokkerende om ikke alt har tålt tidens tann like godt 🙂

Spent på hva det var da. Jeg har nylig vært igjennom og steila ikke veldig. Men det er ikke til å skyve under en stol at når det blir mye så går det litt i bølger hvor godt alt synker inn. Kanskje jeg steiler på andre forsøk 😄

Altså - "jeg har bittelitt i pirke i i kapittel seks" er ganske bra for bøker for min del, vanligvis er jeg mer uenig enn det 😅

Han er mye smartere enn meg! 🤓

Han virker utvilsomt sjeldent intelligent, men det gjør du også. 😄 For meg er likheten i måten å tenke på problemer. Å gå til bunns og ta utgangspunkt i første prinsipper. Og å ikke nøle med å få skikkelig skitt under neglene. Herlig inspirerende!

I dag skal vi få litt skitt under neglene faktisk, demodag på Opal 🎉

@teodorlu på tal om Jupyter kernels. Professorn har gjort en för sin CL-implementation. Han beskriver i videon hur han har replen igång i Emacs (SLIME) och kan uppdatera fundamenten för sin notebook medan den körs. Antar det liknar ett arbetsflöde med Clerk.

Kult! Jeg får ta en titt på videoen :)

❤️ Jag följer Opal på kartan dagligen, @b.brodie. Den är långt norrut just nu. 69.606° N 17.719° E 😃