Clojurians Log v2
clojure-norway
Morn!
Morn!
Morn!
Mornings
Dette er et ganske annet "take" enn "Your tech SUCKS"-artikkelen over. Istedenfor å fokusere på verktøyene vi som programmerere bruker, så kan vi fokusere på produksjon av funksjonalitet basert på verktøyene vi lager - kjernen i appene våre. Med gode definisjoner/spesifikasjoner/eksempler kan LLMene bli gode på våre applikasjoner og effektivt og presist produsere ny funksjonalitet. Folkene bak Storybook jobber med MCPer som muliggjør LLMene å bruke designsystemer definert i Storybook til å produsere brukergrensesnitt og komponenter: https://www.youtube.com/watch?v=Vg78K3t9KYc Dette er en ganske lang presentasjon, men vel verdt å se. Noen takeaways: • vi får LLMen til å produsere brukergrensesnitt i henhold til våre egne regler og praksiser, basert på designsystemet slik det er definert i Storybook hvor LLMen får se spesifikasjoner og eksempler og tester • LLMen blir presis og rask og vil antakeligvis bruke langt færre tokens sammenlignet med om den jobber med hele kodebasen som kontekst • Ettersom det blir raskt å koke sammen nye grensesnitt, så kan dette gjøres live i møter sammen med stakeholders istedenfor å sende screenshots og mockups frem og tilbake mellom diskusjoner og møter. Det korter inn feedback-loopen betraktelig og gir kanskje muligheter vi ikke har hatt før Mine tanker går videre til Replicant og Portfolio og Clojure. Jeg tipper det er hånd i hanske for slikt. Og man kan sikkert argumentere for at det samme gjelder i backend hvor Functional Core / Imperitve Shell regjererer - gitt at kjernen er veldefinert. Morn, forresten 🙂
Jeg tror ogsa vi har bedre LLM-fundament nar vi har tydeligere regler vi kan fortelle den at den skal holde seg innenfor. Og med raskere feedback for LLM-en, evaluer et uttrykk og kjor noen tester i REPL bor ha nar null forsinkelse. Men jeg sier TROR. Dette er spekulasjon, jeg har ikke provd det!
Ja, det er det samme for meg. Dette er antakelser. Det må prøves ordentlig ut, og jeg har fortsatt tilgode å bruke en LLM til å produsere kode.
https://martinalderson.com/posts/which-programming-languages-are-most-token-efficient/
Så den der ja! Morsomt at dynamiske språk som Clojure treffer så bra, mens javascript er såpass mye lavere på stigen! Men synd at det ikke var grunnlag for å inkludere Typescript i denne undersøkelsen.
Morn!
Morn!!
Morn
God morgen!
Er det nokon som brukar https://github.com/ivarref/norwegian-national-id-validator/ eller fødselsnummervalidering? I så fall så er fylgjande kanskje relevant: https://skatteetaten.github.io/folkeregisteret-api-dokumentasjon/nytt-fodselsnummer-fra-2032/. Og då må validatorar oppdaterast til å støtta det, om det ikkje gjer det allereie. Siste versjon av norwegian-national-id-validator støttar no nytt format. Takk til @sigve.nordgaard for å ha oppdaga 2032-formatet og for pull request på repoet 🎉 ❤️
Jeg måtte akkurat veilede en fabrikkarbeider gjennom grunnleggende bruk av terminalen via dårlig videolink, slik at han kunne slette noen filer på et Linux-system de hadde kjørende på produksjonslinjen. Dette var en direkte konsekvens av at jeg bidro til å skrive kode som ikke var bakoverkompatibel. God påminnelse om at noen alltid må betale for hvert dårlige teknologivalg.
For å nyansere bildet noe ble vi lovet at det ikke var noen eldre systemer i produksjon da vi gjorde endringene, men det stemte ikke helt: Det var ett 😅
Den er lei!
on-prem altså... det er et helt eget univers jeg har hatt lite med å gjøre
Jeg har skrevet en raskt lite innlegg med noen tall fra git-repoene våre i 2025, nysgjerrig på hvordan andres tall ser ut: https://parenteser.mattilsynet.io/2025-i-git/
7131 er tallet vårt. Omtrent samme mengde folk (5 utviklere + en som oppdaterer translations innimellom)
Bra trøkk! 😄
Jeg er spent på å se tilbake om et år. Nå er teamet godt etablert og vi har et shit-tonn med greier å gjøre i 2026 😅
677 her. Ca. tre-fire som jobber på prosjektet, utelukkende pull requests (🥲)
Blir commits squasha?
Vi begynte med det ca. halvveis inn i året, tror jeg
Jeg åpnet akkurat PR #345, så vi har ikke alltid gjort det i alle fall
6905!
null pull