Utviklere overdriver faren ved vendor locking
Vendor locking har blitt en slags moralsk panikk i utviklingsmiljøer. Ikke bind dere til Azure. Ikke bruk noe for tett knyttet til Microsoft. Men hvor farlig er det egentlig?
Få inspirasjon og kunnskap
Vi lærer best av og med hverandre. Derfor deler vi gjerne.
I Alv er det mange med sterke meninger. Vi oppfordrer alltid alle å dele på kunnskapen. På denne siden finner du bloggpostene som Alver har skrevet siden starten av Alv i 2019.
Vendor locking har blitt en slags moralsk panikk i utviklingsmiljøer. Ikke bind dere til Azure. Ikke bruk noe for tett knyttet til Microsoft. Men hvor farlig er det egentlig?
Nylig var vi nødt til å skrive om innloggingsflyten i et av våre interne systemer. Der vi tidligere hadde brukt en slags Frankensteins monster av implicit grant flow og noen andre småting fra andre flyter, flyttet vi over til cookie-basert BFF pattern med authorization code flow og proof key for code exchange (PKCE).
Kodebaser blir sjelden komplekse over natten. Det skjer gradvis, gjennom små valg vi tar hver dag. Litt ekstra abstraksjon her, et interface der, en pakke som virker fornuftig i øyeblikket.
Sondre tok oss gjennom hvordan OAuth og OpenID Connect fungerer når man skal implementere Authorization Code Flow.
Jeg opplever stadig oftere at arkitekturvalg i systemutvikling styres av problemer som kanskje kan oppstå om fem eller ti år. Vi designer for ekstrem skalerbarhet, høy last og komplekse scenarioer lenge før det finnes reelle behov for det. Ofte skjer dette på bekostning av å løse de faktiske problemene vi har her og nå.
Det er ikke mange banebrytende endringer, men de få nyhetene som faktisk kommer har likevel potensial til å forbedre måten vi skriver, organiserer og tester kode på.
Her er det jeg har lært så langt (fra nivå1-dårlig til nivå8-ninja)
.net 8 med nye Identity Endpoints oppsett. Vi har tatt en en nærmere titt på det. Er Identity API Endpoints i .net 8 kroken på døra for tredjepartsautentisering?
Mange tenker på Techlead kun som en flink utvikler, mens Techleadene selv ofte tenker på seg selv som et teknisk orakel som bør bestemme det meste. Begge disse ytterpunktene står i veien for god verdiskaping.
Her er 8 viktige punkter når du gjøre review av teknisk arkitektur.
En ny sommer er forbi, og studentene i Alv har avlagt seks intensive uker med frustrasjon, glede og mestringsfølelse.
I denne bloggposter skriver jeg litt om hva som skiller en GOD og en OK utvikler og hvordan vi tester kandidater i Alv for å finne de riktige folkene.
I denne artikkelen vil jeg fokusere på det praktiske rundt clean code og hvordan å gjøre testene dine mest mulig leselige og oversiktlige.
I første del av denne artikkelserien gikk vi gjennom minneproblemer og hvordan å håndtere det å gå tom for tråder eller sockets. Del to så på hvordan CPU- og I/O-begrensinger kan påvirke systemet og hvordan du kan løse dem. I denne delen vil vi forklare med eksempler, hvordan begrensinger i sekvensiell del av programmer krever alternative løsninger og et større konkret eksempel på hvordan vi går frem for å løse slike problemer.
Mikrotjenester er noe man har hørt mye om på konferanser og forum i en stund nå, men sett bort ifra den tekniske løsningen; Hvordan passer dette egentlig inn i et reelt prosjekt og hvilke hensyn må man ta?
Dette er del to i en artikkelserie på tre deler om ytelse. Del en finner du her. Det er 15 år siden man gikk over til flerkjerneprosessorer i konsumentmarkedet. På tross av dette benytter alt for mange applikasjoner i dag kun en kjerne. Det er absolutt på tide å utnytte det gode arbeidet maskinvare har gjort for oss, og ta livet av loading screens og hengende applikasjoner.
Dårlig ytelse kan lett drepe den beste applikasjon! Det er lite som er så irriterende som å jobbe i en applikasjon der all arbeidsflyt blir stoppet opp av ventetid hvert 5 minutt. Det er lett å tenke at dette ikke har så stor påvirkning, da det bare er noen sekunder eller minutter her og der, men det har en stor effekt.