Välkommen till min blogg
Så kul att just du är här! Jag har tänkt att skriva några ord här om min resa inom programmering och teknik, men med några övriga inlägg från mitt liv med dansen också. Hoppas det kan bli en rolig läsning för dig.
Här hittar du inlägg om olika programmeringsspråk, webbutveckling, och mina projekt. Använd navigeringen ovan för att utforska bloggen!
Kategorier
- Advent of Code
- Agilt
- Ai
- Arkitektur
- ArvidsonFoto
- Azure
- Best Practices
- CI/CD
- Copilot
- C#-kod
- CSS-kod
- Dagbok
- Dans
- DevOps
- .NET
- Felhantering
- Frontend
- Git
- GitHub
- Hemsidan
- HTML-kod
- JavaScript-kod
- Konferens
- Ledarskap
- Livsstil
- Migrering
- MVC
- Observerbarhet
- Produktivitet
- Programmering
- Release Pipelines
- Rikedom i livet
- Säkerhet
- SQL
- Systemutveckling
- Testning
- Verktyg
- Visual Studio
- WCAG
- Web
- webbutveckling
- Youtube
Senaste inläggen
-
Bemästra .NET 10 Options Pattern — IOptions vs. IOptionsSnapshot vs. IOptionsMonitor
Att hantera konfiguration i ett modernt enterprise-system handlar om betydligt mer än att bara läsa en sträng från
appsettings.json. I storskaliga system – som ofta bygger på arkitekturer som Vertical Slice Architecture, distribuerade mikrotjänster och molnbaserad infrastruktur – blir hanteringen av inställningningarnas livscykel (lifetime) helt kritisk.Om du injicerar fel typ av Options-gränssnitt riskerar du allt från subtila buggar med datakonsistens under en HTTP-request, till applikationskrascher på grund av Captive Dependencies (fångade beroenden).
I .NET 10 har vi tre primära verktyg för att läsa konfiguration:
IOptions<T>,IOptionsSnapshot<T>ochIOptionsMonitor<T>. Låt oss gå till botten med exakt hur de fungerar, hur de presterar under huven och hur du väljer rätt i din arkitektur. -
Från Classic till Kod: Så bygger du en Modern Multi-stage Pipeline i Azure DevOps
I den moderna DevOps-världen räcker det inte längre med att bara ha applikationskoden under versionshantering. Att klicka sig fram i grafiska gränssnitt för att bygga bygg- och driftsättningsflöden – så kaldade Classic Release Pipelines – är ett föråldrat arbetssätt som skapar underhållsskulder, bristande spårbarhet och konfigurationsavvikelser (configuration drift).
För att bygga en riktigt skarp, robust och automatiserad release- och deploy-pipeline i Azure DevOps bör du helt överge det gamla grafiska gränssnittet och fullt ut satsa på YAML Multi-stage Pipelines.
Med detta tillvägagångssätt tillämpar du principerna för Pipeline as Code (PaC). Hela din CI/CD-arkitektur deklareras i en textfil som versionshanteras i ditt Git-repository, precis som din vanliga C#- eller .NET-kod. Det innebär kodgranskning (Pull Requests) för infrastrukturändringar, fullhistorik och enkel återställning.
-
Skapa en gemensam vision: Så kartlägger ni systemlandskapet tillsammans med C4-modellen
Att hålla reda på en växande applikationsportfölj är en av de största utmaningarna i moderna utvecklingsorganisationer. När systemen passerar 20+, eller till och med närmar sig 100+ olika applikationsdelar, blir det snabbt omöjligt att bibehålla en gemensam syn om ingen har en tydlig helhetsbild.
Att dokumentera allt i tunga textdokument tröttar ut vem som helst och leder till passivitet. För att bryta silon mellan era utvecklingsteam krävs en visuell, interaktiv och levande metod där arkitekturen ritas upp gemensamt.
-
Från kodknackare till Force Multiplier: Hur du skalar din påverkan i en stor organisation
I en mindre startup eller ett litet autonomt team mäts din framgång ofta i hur mycket kod du producerar. Ju snabbare du stänger dina Jira-tickets och ju fler rader kod du trycker ur dig, desto mer värdefull är du.
Men när du kliver in i en större organisation förändras spelreglerna helt.
I en miljö med dussintals team, hundratals mikrotjänster och utspridda legacy-system blir det mänskliga taket för kodproduktion snabbt en flaskhals. Om du bara fokuserar på din egen backlog blir din påverkan linjär. För att verkligen växa och göra skillnad måste du skifta fokus från din enskilda kod till det större systemet och människorna runt det.
Du måste bli en Force Multiplier (kraftmultiplikator).
-
Navigera i utvecklarvardagens kaos: Cynefin-ramverket som din mentala kompass
Har du någonsin börjat dagen med att lugnt konfigurera en CI/CD-pipeline, kastats in i ett akut produktionshaveri före lunch, spenderat eftermiddagen i ett luddigt möte om “framtida användarbehov”, för i att avslutat dagen med att ändra en textsträng i ett UI?
Som systemutvecklare förväntas vi ofta växla mellan dessa uppgifter sömlöst. Men sanningen är att de kräver helt olika delar av vår hjärna. Att misslyckas med att se skillnaden på dessa problem är en av de största källorna till stress, utbrändhet och – inte minst – teknisk skuld.
För att förstå varför vissa dagar känns som en harmonisk dans och andra som ett krigszon, kan vi ta hjälp av ett av systemvetenskapens mest kraftfulla verktyg: Cynefin-ramverket.
-
Skaparens vs. Administratörens Schema: Nyckeln till att Återta din Mentala Energi och Flow
Har du någonsin avslutat en arbetsdag med känslan av att vara helt utmattad, men när du tittar tillbaka på dagen inser du att du knappt har hunnit producera något konkret?
Du är inte ensam. Denna smygande frustration och mentala dränering drabbar tusentals utvecklare, skribenter, designers och kreatörer varje dag. Men det handlar varken om brist på disciplin eller lathet. Det handlar om en fundamental, kognitiv krock mellan två helt olika sätt att strukturera tid: Skaparens schema (Maker’s Schedule) och Administratörens schema (Manager’s Schedule).
-
Modernisera din byggstruktur när du uppgraderar till .NET 10
Att kliva från en .NET 8-applikation – speciellt en som bär på legacy-bagage – direkt till .NET 10 är ett fantastiskt tillfälle att inte bara lyfta ramverket, utan att faktiskt städa bort teknisk skuld. För att göra kodbasen mer lätthanterlig, enhetlig och framtidssäker bör fokus ligga på att centralisera inställningar, utnyttja kompilatorn hårdare och implementera moderna arkitekturmönster.
I den här artikeln går vi igenom hur du sätter upp en modern, strömlinjeformad projektstruktur från grunden med hjälp av det nya
.slnx-formatet,global.json,Directory.Build.props, och Central Package Management (CPM medDirectory.Packages.props). -
Migrera dina gamla SSDT-databasprojekt till SDK-style SQL-projekt
För oss som bygger moderna .NET-lösningar – kanske med en Vertical Slice-arkitektur och med siktet inställt på .NET 10 – är smidiga CI/CD-flöden helt avgörande. Ett historiskt smärtområde i våra Azure DevOps-pipelines har varit databasprojekten. Klassiska SQL Server Data Tools (SSDT)
.sqlproj-filer är ökända för att skapa enorma merge-konflikter eftersom varje enskild fil måste registreras i en gigantisk XML-struktur [1].Lösningen stavas SDK-style SQL-projekt. Genom att använda Microsofts SDK
Microsoft.Build.Sqlfår vi minimala projektfiler, wildcard-inkludering av skript och fullt plattformsoberoende kompilering via kommandoraden.Här är en komplett guide till hur du migrerar dina gamla databasprojekt till det moderna formatet, hur filstrukturen bör se ut och en viktig varning gällande stödet i Visual Studio 2026.
-
Vad är nytt i DIGG:s nationella REST API-profil? Från v1.1.0 till v2.0.0
Om du har designat och byggt API:er för den offentliga sektorn under de senaste åren är chansen stor att du har använt DIGG:s (Myndigheten för digital förvaltning) nationella REST API-profil, troligtvis version 1.1.0. Syftet med profilen har alltid varit att standardisera och skapa interoperabilitet mellan offentliga aktörer.
Nyligen lanserades version 2.0.0 av REST API-profilen. Om du inte har haft tid att plöja igenom den uppdaterade dokumentationen ännu, är denna bloggpost för dig. Vi går igenom de största nyheterna, vad du behöver läsa in dig extra på och de relevanta standarder och RFC:er som styr arkitekturen.
-
DIGG:s nya REST API-profil (v2.0.0): Så bygger du moderna, spårbara och robusta API:er i .NET 10
Offentlig sektor i Sverige digitaliseras i en rasande takt, och i navet av denna utveckling hittar vi Myndigheten för digital förvaltning (DIGG). Med lanseringen av REST API-profil version 2.0.0 (nu den 16 juni 2026) har ribban höjts. Fokus har flyttats från isolerade system till hur API:er samverkar i stora, distribuerade kedjor över organisationsgränser.
För oss som bygger system i .NET-ekosystemet är tajmingen perfekt. Med .NET 10 har vi inbyggda, kraftfulla verktyg för att möta dessa nya, strikta krav. Här går vi igenom de största nyheterna i v2.0.0 (och uppstramningarna från 1.2.0) och tittar på hur du implementerar dem rent praktiskt i C#.
-
Fixa de "osynliga" uppdateringarna: Så hanterar du statusmeddelanden enligt WCAG 2.1
När vi bygger moderna, dynamiska webbapplikationer strävar vi ofta efter en sömlös användarupplevelse. Vi använder asynkrona anrop för att spara formulär, lägga till varor i en kundvagn eller hämta in nytt data utan att ladda om sidan. Visuellt är detta fantastiskt – en liten grön ruta dyker kanske upp med texten “Dina ändringar har sparats!”.
Men vad händer för de användare som inte ser skärmen och förlitar sig på skärmläsare? Ofta: ingenting alls.
-
Mörkt läge/Dark Mode: Inte ett lagkrav, men viktigt för dina användare (Så implementerar du det)
“Måste vi verkligen bygga ett mörkt läge för att uppfylla tillgänglighetskraven?” Det är en av de vanligaste frågorna när organisationer ska anpassa sina digitala tjänster efter DOS-lagen och det europeiska tillgänglighetsdirektivet. Svaret är både enklare och mer komplext än man kan tro. Låt oss reda ut juridiken, den medicinska vetenskapen och hur du bygger en skottsäker teknisk arkitektur.