Ja, det er liksom en type problem man nesten er nødt til å bli ekspert på med en gang man pusler med det, uten at man helst hadde lyst til å bli ekspert på det 😐 På Nais-plattformen i Nav har vi noe som heter “https://docs.nais.io/appendix/wonderwall/” som liksom skal hjelpe teamene til å ikke måtte forholde seg til detaljer rundt autentisering osv, men vet ikke hvor mange som har tatt det i bruk da det er ganske nytt.

https://github.com/magnars/java-time-dte

kult!

Hadde akkurat dette problemet hos Norled, så dette libbet har fått testet seg ganske grundig, ettersom det også er i bruk der vi er i dag. 🙂

er det noen større og dypere tanker bak at f.eks local date mappes til en string, i stedet for noe som “dager siden epoch” som long elns?

mest lesbarhet hvis du ser rett i indeksen, også matcher det hvordan java.time konstruerer disse

Hvis man mapper til epoch-seconds så gjør man seg vel plutselig avhengig av tidssonen til systemet som skriver/leser også? Skriver man en lokal dato inn i basen fra et system i Europa skal det jo leses ut likt i USA tenker jeg, ellers er det vel ikke en local date

med epoch-tid så mener man vel “tidssoneløst” som i det er gitt at tiden er i UTC 🙂

men det jeg tenkte på var å lagre det som dager siden epoch altså, ikke epoch-seconds

jo, så kan man gjøre om til en local-date derfra, men i utgangspunktet så er det jo cleanere å ikke trenge gjøre om fra UTC heller - selv om det blir mest av alt en implementasjonsdetalj.

(for å ha muligheten til å gjøre range queries på datoene, eks alle datoer før X osv)

det kan man vel strengt talt med strenger også 🙂 "2020-01-01" < "2023-01-02"

:thinking_face: Epoch-tid har vel et tidssone-aspekt ved seg så man må konvertere til og fra UTC, og da er man jo allerede kjørt? Lagrer man som dager siden så kan man også få feil dag når klokken er nær midnatt avhengig av hvilken tidssone man henter ut fra. Men hvis tanken feks bare er å konvertere local datetime til “sekunder siden år 0 i min tidssone” så hadde det kanskje fungert 😅

(eller dager siden år 0)

det jeg tenkte på var å lagre 1970-01-01 som 0, 1970-01-02 som 1, 1970-02-01 som 30, osv

men, i praksis har vi ikke data i systemet før år 1000 og etter år 10 000 så en string vil jo faktisk fungere fint for range queries ja!

tviler på at en irritert utvikler i år 10 000 vil anklage oss for å ha gjort det sånn når de sitter og vedlikeholder appen for å registrere nyfødte griser

lettere å lese queryen også, i tillegg til at implementasjonen slipper å kjenne til skuddår.

apropos (?): satt og lurte på her om dagen hva neste store kilde til rewrites blir. Nå er vi snart igjennom å ha gjort om gamle webapper til å bli mobilvennlige. Hva kommer til å skje om 1, 10 eller 20 år som gjør at man bare må skrive om de Clojure-baserte mobilvennlige webappene vi lager nå?

ja, den som vet det kan antagelig gjøre store penger 😊

“det blir alt for uøkonomisk å ikke kunne bruke VR-brillene til å gjøre CRUD i metaverset”

“denne appen fra 2024 er alt for lite optimalisert for neuralink-input”

Jeg har tenkt en del på at mange react og shadow-dom-baserte javascript-apper vil bli skrevet om til å ha mer server-side rendering sånn på kort sikt :thinking_face:

JS-verden er på index.php-kjøret for tiden, blir spenennde å se hvordan det går 😄

masse hype for at man nå kan ha SQL direkte i react-komponentene sine

Jeg vet ikke svaret på spørsmålet ditt, men det fikk meg umiddelbart til å tenke på https://stackoverflow.com/users/22656/jon-skeet og hans bibliotek, https://nodatime.org/, som jeg tror var inspirert av Joda Time (men Noda Time har blitt fullstendig skrevet om i ettertid, så vidt jeg forstår). Jon Skeet har skrevet masse om slike ting og merkelige problemstillinger som har med tid å gjøre. Bare en liten aside.

Ja, java.time er laget av samme person som lagde Joda Time i sin tid, men denne gangen gjort riktig. Det er et helt utmerket tidsbibliotek. Gjetter på at det er en av grunnene til at Noda Time også er fullstendig omskrevet.

https://pca.st/episode/4880d570-3325-4de5-8cb2-0b401148b20c er ganske bra og gir en del innsikt i problemene og historien. Jeg synes det var ganske interessant!

Visste ikke hva keep gjorde før jeg slo den opp nå. Takk! Og jeg må innrømme at det nesten var enda mer gøy å se dere spille på slutten enn å kode. Det var nesten så dere døde 😁

Ja, det ble ganske artig til slutt der 😄

Hvordan har det vært å lage? Stress? Gøy? Har dere lært noe?

Det var bare gøy, vil jeg si. Litt styrete å skulle lage en episode i uka - og det fikk vi jo ikke alltid til heller - men veldig trivelig prosjekt.

Jeg har tenkt å prøve å sette ord på hva vi lærte, men jeg tror lærdommen kommer best til syne når man sammenligner med Parens of the Dead. Ganske stor forbedring der.

Kult! Jeg føler det ofte blir sånn med å lære praksis, i stedet for teori. Dere har jo valgt å gjøre en ekte greie på ekte måte. Ikke å forelese om noe teori. Synes alltid sånt er vanskeligere å formulere. "hvorfor driver vi egentlig med enhetstesting?" "joo, nå skal du høre ...".

Ja, det blir "show, don't tell" i praksis. Det er ikke så lett å kommunisere fordelene med et REPL, for eksempel, skriftlig (selv om @U9MKYDN4Q har gjort et hederlig forsøk https://www.kodemaker.no/blogg/2022-10-repl/) - så er det enkelte ting man nesten må se for å tro. 🙂

GIF-ene er bra, da! Kult at dere bare har en funksjon som returnerer assets. Ikke noe magisk ring middleware.

ja, det er optimus 🙂