Jeg tror at Clojure ikke får noe utbytte av Static Images, altså denne delen som snakkes om i Beginnings hvor man da ikke har dynamisk genererte klasser. Tror ikke det er kompatibelt med hvordan Clojure interpreteren gjør ting, men kan kanskje fungere med AOT?

In the world of frontend development, one thing remains certain: change is the only constant. New frameworks emerge, and libraries can become obsolete without warning."I did not know that. I still don't know that"

ah, har ikke sett Simple Made Easy på en stund, på tide med et gjensyn. Her med timestamp til Christian sin referanse: https://www.youtube.com/watch?v=SxdOUGdseq4&t=850s

Så, gitt at de ikke hadde lagt ut på denne AI reisen (som de ikke har spesifisert noe timebruk på), så estimerte de 10000 timer på å skrive om testene, fordi de skulle fra R17 til R18. Jeg antar at dette kanskje ikke var den eneste kostnaden. Et spørsmål må jo da bli, hva var oppsiden? For den bør jo være ganske stor…

den artikkelen heller bensin på bålet mitt om nytteverdien av å teste GUI-komponenter på den måten

Har ikke rukket å lese dette, men dersom det å oppgradere én majorversjon er estimert til 10k timer så er jeg rett og slett tom for ord. Da ville jeg starta med å sparke samtlige som har vært involvert i å bygge faenskapet.

“vi drar inn en dependency for å teste mot noe internals i React, vi, det er lurt” 😬

Det var bare å skrive om testene som var estimert til 10k timer. Artikkelen sier ingenting om resten.

At de i det hele tatt tør å skrive dette offentlig sier litt om hvor ute å kjøre de er

Dette er jo en kjempewin! Et problem har oppstått, de har kunnet applisere AI for å løse det. Finnes det noe mer fremoverlent og sexy enn det?

det er jo bransjestandard og best practice å bare dra inn masse dependencies

Det er som å skrive en bloggpost om hvordan man kan få inn mer søppel i dette huset. Med AI!

liker også at de byttet fra enzyme (et uoffisielt teste-bibliotek som jobber med internals i React) til React Testing Library (et uoffisielt teste-bibliotek som jobber med internals i React)

Kriminelt inkompetent

fwiw er ihvertfall React Testing Library basert på å teste på DOM-output, og ikke intern state og oppsett av React-komponenter, så det er vel et steg i riktig retning sånn sett

Det er helt irrelevant i hvilken retning du tar stegene dine når du er så hinsides langt ute på viddene

Dette er det slutten på historien som starter med utsagnet "la oss bruke React til routing"

"Jeg skal til USA, så å gå til butikken er et steg i riktig retning"

om ikke annet er det ganske grei konsensus på HN om at dette var rævva, eller i det minste snodig https://news.ycombinator.com/item?id=40726648

har også 1 som tallet på “antall prosjekter jeg har fjernet React Router fra” 💪 Fikk det også til uten AI, tro det eller ei

> > saving considerable developer time of at least 22% of 10,000 hours > I wonder how much time or money it would take to just update Enzyme to support react 18? (fork, or, god forbid, by supporting development of the actual project). > Nah, let’s play with LLMs instead, and retask all the frontend teams in the company to rewriting unit tests to a new framework we won’t support either. > I guess when you’re swimming in pools of money there’s no need to do reasonable things.

Furthermore, as a member of the Frontend Test Frameworks team (╯°□°）╯︵ ┻━┻

For noe forbanna ræl. Jeg prøvde å lese artikkelen, men blir så provosert av problemstillingen at jeg ikke orker å høre detaljer om hvordan de gikk frem for å løse det. Snakk om å angripe feil problem.

Snakk om å angripe feil problem.> Mer seriøst spørsmål - hvis man er i denne situasjonen, hva gjør man egentlig? Metodisk fjerne ting etter ting? (ref begynne å ta ut søpla)

Godt spørsmål, det er en helt håpløs situasjon som nesten ikke fortjener et seriøst svar. At ingen har reagert før de har problemet i det absurde omfanget de har nå er i mine øyne seriøst graverende nok til at jeg ville vurdert å fjerna en hel haug med folk.

Men forslaget fra hackernews som @U04V5VAUN fant er vel eneste fornuftige vei fremover

det kan umulig ta i nærheten av 10k timer å ta over vedlikeholdet av det testrammeverket

Alternativ: innfør en shim/proxy for rammeverket, og bytt ut alle kall. Nå har du ett sentralt sted der du kan bytte ut rammeverket.

Men du sitter fortsatt på 10k tester som tester UI-et ditt ca like mye som de tester random implementasjonsdetaljer i React. Det problemet kommer de aldri til å få løst.

Unnskyld, 15k tester 😂

Litt synd når løsningen er å si opp folk - men ja, vanskelig å si at dette ikke er et problem med teamet.

Det er grovt inkompetent

Hvor lenge til hele kodebasen er basically umulig å jobbe videre med?

Shim gir mening ja. Man må vel tenke at ting kommer til å være "halvveis dritt" i det rommet en stund før det faktisk blir bra.

Tror ikke det har utsikter til å bli bra. Kanskje mindre dårlig enn det er nå.

At de har valgt å skrive testene sine på denne måten sier meg en god del om arkitekturen på den underliggende koden.

(Noe fordomsfullt selvfølgelig, men jeg setter en femtilapp på at jeg ikke bommer helt 😅 )

https://clojurians.slack.com/archives/C061XGG1W/p1719563963992459?thread_ts=1719561094.731999&cid=C061XGG1W Når jeg leser denne blir jeg sittende og tenke at det handler om kompetanse og selvtillit Hvis man tenker at man ikke kunne skrevet et bibliotek for testing, og ikke tør starte, blir ikke status quo bedre. Men ... jeg kjenner også at jeg kanskje ikke ville ønsket å bruke et bibliotek som disse menneskene har laget.

🎯 😂

Jeg synes også det er vondt å tenke på at en glorifisert irc-klone trenger 15K unit-tester

Ikke unit tester, e2e UI-tester 😂

Huff, jeg klarer ikke stoppe. Ser dere det fancy, ai-genererte bildet? Legger dere merke til noe? Overgangen fra trad-engineering (venstre) til ai-engineering (høyre) er ren sminking. • Kranene er blå • De er selvlysende • Og de er av en eller annen grunn tykkere. Så... Kranene er dyrere å produsere, og bruker mer strøm. MEN alle folka er borte, da. Så er moralen, fjern folka som tenker, aksepter at det fører til dyrere, dårligere produkter, men mal det med selvlysende blå maling, og erkær det som en suksess?

> denys_potapov 8 days ago | prev | next [–] > > It's a 2024 webdev summary, nothing can be added: > > New React version made the lib obsolete, we used LLM to fix it (1/5 success rate)

rart hvordan man kan se og/eller mageføle når illustrasjoner er AI-genererte

behovet for å render-teste GUI-kode kommer vel ene og alene fra dårlig (eller mangel på) datamodell, som ikke kan testes for seg selv? Med en god (og logikk-tykk) datamodell er behovet ganske lavt for å teste selve render-koden

Jepp, dette er en av flere ting som gjør at jeg mener dette er katastrofalt inkompetent

og selv når man har state over alt og gjør “vanlig” React er det bare litt tankekraft som skal til for å skrive state-logikken som isolert kode man kan unit-teste

jeg vil nesten si at det er et rødt flagg for kodebasen om du ikke tør å prodsette kode uten render-tester

apropos alt som har blitt sagt om å få domenet ut av render-steget

Jøss. Til tross for hvor mye de fikler og kåler hos Slack, så har produktet deres blitt svært utbredt og de tjener voldsomt mye penger. Det er interessant at selskaper som gjør dårlige tekniske valg allikevel kan gjøre det så godt forretningsmessig.

En kan spørre seg om gode teknologivalg egentlig er avgjørende for forretingssuksess. Kanskje det ikke spiller noen rolle hvor dårlig ting er implementert på så lenge ideen og brukeropplevelsen er god.

Dog kunne de antagelig tjent mye mer penger (kastet bort mye mindre penger) hvis tingene var implementert på en god måte.

Så man kan lage gode produkter på en dårlig måte, og dårlige produkter på en god måte. Den store forskjellen ligger i kostnaden for utvikling, vedlikehold, og drift. Hvor stor regninga blir og hvor lang tid det tar. Noen har mer penger å sløse enn andre.

Jeg har tenkt litt at god tech og gode produkter koster fokus. Og du har begrenset mengde total fokus. Jeg velger å tro at det beste er å få til begge i parallell, god tech og gode produkter. Men i praksis har jeg ofte observert det motsatte: at team som jobber med svært hyppige iterasjoner på brukeropplevelsen gjerne gjør kompromisser på koden, eller at team som har svært god kontroll på koden blir defensive når man har lyst til å eksperimentere med produktet. For Slack sin del tenker jeg: • de har et produkt som selger som hakka møkk, de har buffer nok til å gjøre veldig mye feil. • så lenge “eksisterende arkitektur” ikke opptar med enn 50 % av teamene sin kapasitet, kan de nok fremdeles få til å lage nye ting. Jeg vil si at personene det går mest utover at man har dårlig teknologifundament er utviklerene som jobber der; de lærer den måten å gjøre det på som den eneste måten som finnes. Som er synd.

Å holde kvaliteten oppe på koden når mange folk er innom er et par hakk vanskeligere enn når 1-3 personer jobber på koden, etter min erfaring.

Jeg tenker at teknologien er god når den tillater så få mennesker som mulig å lage relativt sofistikerte og lukerative produkter og tjenester på en god måte og innenfor en noenlunde fornuftig tidsramme. Alle steder jeg har jobbet har forretningssiden stresset med "Time to Market." Det skulle helst vært lansert i går. I de fleste tilfeller ville jeg foretrukket å velge ideer hvor dette med "Time to Market" ikke er så viktlig, slik at man kan ha færre folk og bruke mer tid.

Det er en av tingene @christian767 og @U07FCNURX har vist meg: Hvor mye en kan gjøre med få (dyktige) folk på laget. Man trenger ikke flere titalls eller hundrevis av utviklere i de fleste tilfeller hvis man gjør gode teknologivalg. Store teams kompliserer ting unødvendig.

AAA spillutvikling er en litt sær produktkateogri der 😅

Store team kompliserer utvilsomt. Dette med time to market brukes ofte som en unnskyldning, men jeg tror ikke det er en god forklaring. Jeg tror forklaringen heller ligger i dårlige bransjestandarder (altså lista for hva som er akseptabelt å drive med ligger altfor lavt), for mange uerfarne folk, og for lite godt teknologisk lederskap. Jeg vil tro at time to market-grafen til Slack ser rimelig dyster ut etter mange år med det kjøret de har holdt på med. Til slutt når sånn kode et metningspunkt der du bare ikke får til å stappe inn mer funksjonalitet uten å rase hele tårnet.

Min drøm er å sitte i ett rom med en håndfull personer og kunne snu seg rundt og prate med hverandre ved behov. Face-to-face. Ikke noe e-post. Ikke noe Slack. Ikke noe Teams. Bare virkeligheten.

Jeremy er flink, han har også masse egne videoer om NATS