mer, gjør alt for lite av det

Er det fordi du ikke er på team hvor det er noen det passer å programmere med? Eller har dere bare for mye å gjøre til å rekke å sette dere ned i ro og mak sammen?

er ikke en del av kulturen hos inneværende kunde

nå som vi snakker om det slår det meg at jeg burde gjort en liten innsats her

det er ikke ansett som effektiv bruk av tid når ikke alle sitter og skriver kode?

Jeg er ikke spesielt glad i parprogrammering, men jeg liker pardesigning.

så … gjørejobber for seg selv, gå sammen for å ta tyngre beslutninger?

Godt oppsummert

Det er litt sånn jeg har oppfattet at @U9MKYDN4Q og @U07FCNURX parprogrammerer?

Skissere noen alternativer sammen, gjerne i kode, og så krønsje ut hver for seg?

Ja, til en viss grad. Vi sitter en del sammen, så lenge det er "interessante valg å ta". Litt flytende grense der, men vi deler oss stort sett når det er mest snakk om å banke ut mer av det samme.

Vi skriver nok mer kode sammen enn du antyder @U04V5VAUN 🙂

Nå driver vi feks og formulerer en datamodell, det skjemaet skriver vi i sin helhet sammen.

@U9MKYDN4Q vil du skissere grovt hvor mye dere sitter sammen i forhold til hver for dere? Er ish 50/50, eller er det mer 80/20 i en retning?

Det er vel sånn jeg kanskje hadde gjort sammen med noen på tavla, tegna opp et ER/NIAM diagram og så kanskje implementert selv.

Vi skriver Datomic-skjema sammen. Det er en måte å tenke om data på som passer meg godt.

Right.

@U3X7174KS jeg vil si at det svinger litt etter hvilken fase vi er i. La oss si at det snitter til 50/50, og tidvis er 90/10 i den ene eller andre retningen eller noe sånt? Litt vanskelig å tallfeste.

skjønner, takk 🙂 Full forståelse for at dette ikke er konstant hver uke. Men da kan man lett si at man “ikke programmerer som dere” hvis man kun sitter sammen torsdag morgen én time hver uke!

Nei, det er et stykke fra vår arbeidsflyt 😅

Jeg parprogrammerer mer enn det med @U06P2F094Q0 og han er ikke engang på samme team som meg 😄

Jeg har hatt så mange parprogrammeringsopplevelser av typen "Dette jeg trodde jeg helt fint kunne stunte sjæl ble bedre når vi satt sammen om det" at jeg lett ser verdien.

Jeg tror kanskje også det krever et lite “tillitsprang” å lene seg inn i det; at man må gi litt ekstra goodwill den første gangen / de første gangene man prøver. Særlig når én (eller begge) ikke har gjort noe særlig parprogrammering før.

Helt klart, det er en ferdighet å mestre som alt mulig annet. Krever trening, tillit og en viss personkjemi.

Men det finnes ingen bedre måte å sørge for at et team jobber enhetlig

Selv har jeg egentlig aldri tatt parprogrammering / ensemble-programmering seriøst før i år. Og det innser jeg nå at jeg synes er litt … rart. Men handler vel mye om hvem man får mulighet til å jobbe med tidlig.

Ja, det er litt tilfeldig hva man ramler inn i av sånne ting 🙂

I det gamle teamet mitt satt vi sammen 3 stk. ca. 2 timer 3 ganger i uka. Man får noen gode diskusjoner og innsikter i hverandres oppgaver og tanker, men hadde ikke klart å sitte sammen 100% av tiden 😅 Men det er kjempegodt for kompetansedeling og semistore beslutninger

Hadde kanskje ønsket å gjøre det mer adhoc, men for å bare komme igang hjelper det med faste tidspunkter 🙂

Jeg har kjørt en del parprogrammering sammen med to kollegaer i det siste. En ting jeg har måttet lære er å … ta det litt rolig. Ikke prøve å gjøre alt på en gang. Ta tid til diskusjon, ikke bli utålmodig når ting tar litt tid. Og at når vi er 3, er det helt OK at én person går litt til side og gjør andre ting (feks fordi personen trenger en pause), og blir med igjen når det passer.

men dette må jo bety at jiraer blir flyttet til høyre halvparten så kjapt? Hvordan ser det ut på burndown charts?

Da SMELLER vi bøkene til Marty Cagan i bordet og sier at her på teamet jobber vi for å løse ekte problemer for ekte folk, ikke for å gjøre jobb!

en god del parprogrammering på prosjektet, funker bra enten for å løse spesielt tunge oppgaver sammen, eller som en del av opplæring av nye på teamet.

For lite, ønsker mer, med sliter med å prioritere det…

helt fra sidelinja, norsken din er skikkelig god!

Takk! Det er ikke helt min norsk ännu, utan Nybegynnerspråkeventyrerens 😃 Utom dette svar da, som jeg skrevet helt selv. Haha.

Som enligt GPTn kunde varit: > Takk! Det er ikke helt min norsk ennå, men Nybegynnerspråkeventyrerens 😃 > Bortsett fra dette svaret da, som jeg har skrevet helt selv. Haha.

Jag vet inte tillräckligt om Replicant för att ha en speciellt värdefull åsikt, men det där ser väldigt trevligt ut!

Trenger ikke å vite noe om replicant for å ha meninger om hvordan koden leser 😊

😃 Jag menar att jag saknar sammanhang och kunskap om alternativ/begränsningar och dylikt.

Hehe. Jeg var bare litt nysgjerrig på hva folk tenker om dette. Dette lar deg gjøre transformasjon av data "just in time", altså bare når replicant trenger å oppdatere DOM-en. Tidligere har jeg løst i18n på en tilsvarende måte, men med en walk før rendering. Ved å ha en hook i replicant kan du få det til med mye bedre performance.

Jeg har også en hypotese om at dersom man kan uttrykke strukturen i UI-et uten alle renderingdetaljene (som button er et eksempel på), så trenger man ikke domenedata -> uidata -> hiccup. Du kan gå rett fra domenedata til hiccup på denne formen.

Dette er veldig interessant!

Hva er det som gjør dem "lettvekt"?

Tja, mulig feil ord? Det er bare mapping av data, ikke noe state eller andre ting man forbinder med komponenter. Så egentlig ikke komponenter i det hele tatt. Men det er effektiv data-transformasjon, siden det kun gjøres idet DOM-en oppdateres - ikke hver gang du "rendrer".

Jeg tenkte ikke på ordbruken, egentlig. Det er bare ikke helt klart for meg hva som er nytt her. (Obs: Jeg har ikke brukt Replicant ennå selv, og heller ikke dumdom, dessverre, bare skummet readmeene nå og da.)

Jeg vet heller ikke om jeg skjønte hvordan dette påvirker performance (men jeg tar deg på ordet assa 😅). Jeg ville anta at den virtuelle DOM-en tar vare på resultatet av (app state), og at det er kun når en node skal rendres at du transformerer med hensyn til :aliases? Gitt at transformasjonene i :aliases genererer mye gørr, så er jo det gørr man slipper å generere for hver rendring. Er jeg inne på noe?

Aha, så det var ikke i seg selv noe nytt ved hvordan man lager komponenter? Man skriver f.eks. button som man gjorde før? 🙂

(defn button ...)

Det demrer for meg nå, ☀️

@U19EUKYLT stemmer!

Det er egentlig bare "late binding" for hiccup-generering

Og en slags generalisering av Hiccup? Du binder et keyword til en funksjon med :aliases , og så rendres dette keywordet ved å kalle funksjonen, men bare hvis denne DOM-noden faktisk skal realiseres, altså vises på skjermen. Keywords som ikke fins som alias rendres bare som vanlige DOM-elementer. Noe sånt?

Premie til @U06BEJGKD! Litt usikker på hva som er riktig oppførsel for keywords som ikke finnes som alias. Enn så lenge rendrer den en div med barna i og rapporterer en feil i konsollet.

Betyr det at du har enumerert alle gyldige html-tags?

Når du skriver [:p "yo"] - er det riktig å tenke på :p som et alias til en funksjon som lager et p-element i DOM-en?

Jeg liker uansett retningen, og er glad hvis dette betyr at man slipper walk for å låse i18n (slik du gjør i m1p). Du sitter på tallene, kanskje - er det for hastighet først og fremst at du prøver denne veien?

@U07FCNURX Nei, det ville jeg unngå. Løsningen ble at aliases må ha namespace.

Men i prinsippet kunne jeg slått opp alle tags i alias-definisjonene, men jeg er usikker på om jeg ønsker at det skal være mulig å redefinere :a 😅

@U06BEJGKD ref [:p "yo"] ja, men jeg har enn så lenge valgt å ikke støtte det

Og ja, å kunne gjøre feks m1p i18n uten walk var hovedmotivasjonen for dette. Kan sikkert brukes til andre cross-cutting ting også.

Forøvrig kan man også gjøre dette:

[:ui/button#special.btn-primary {:actions [[:do-stuff]]}
 [:i18n/k :click]]

nice 👌 😄