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
-
Att tämja felhanteringen: Så bygger du ett smart, delat felbibliotek i .NET
I en växande mikrotjänstarkitektur eller en organisation med tiotals olika applikationer blir felhantering snabbt vilda västern. Ett team returnerar råa strängar, ett annat kastar generiska
500 Internal Server Errorför valideringsfel, och ett tredje uppfinner sitt eget slutpunktformat. När arkitekturen växer till ett 20-tal appar med hundratals unika interna felkoder blir bristen på enhetlighet en ren mardröm för både frontend-utvecklare och supporttekniker.Lösningen är inte att tvinga alla utvecklare att skriva hundratals rader repetitiv
try-catch-logik. Svaret är att centralisera arkitekturen i ett internt, delat NuGet-bibliotek.Här är en ritning för hur du bygger ett enhetligt, utökbart och säkert felhanteringsbibliotek baserat på modern .NET-arkitektur.
-
Gör telemetri enkelt: Bygg ett gemensamt NuGet-paket för .NET Aspire och OpenTelemetry
Tänk dig att du leder en organisation med ett 20-tal olika applikationer och mikrotjänster. Du vill ha perfekt observerbarhet – strukturerad JSON-loggning, distribuerad spårning (Distributed Tracing) och prestandamätetal (Metrics). Men du vill inte tvinga varje enskilt produktteam att bli experter på OpenTelemetry-arkitektur, Serilog-konfiguration eller DevOps-pipelines.
Lösningen? Du bygger ett internt NuGet-paket (t.ex.
Company.Telemetry) som paketerar organisationens best practices. Det bästa av allt? Genom att hålla oss strikt till .NET-standarder somILoggerochActivitykan produktteamen logga precis som vanligt, medan vårt paket sköter magin under huven – oavsett om de kör lokalt med .NET Aspire eller i produktion mot en central OpenTelemetry Collector.I den här bloggposten går vi igenom exakt hur du bygger detta paket.
-
Observerbarhet med .NET 10 och OpenTelemetry: Från Noll till Aspire-Ready
Att bygga distribuerade system och mikrotjänster utan ordentlig insyn är som att köra bil med förbundna ögon. När något går fel vill du inte leta febrilt i isolerade textfiler på fem olika servrar. Du vill ha en sammanhängande berättelse som visar vem som gjorde anropet, vad som hände och varför det tog tid.
I .NET 10 är OpenTelemetry (OTel) den absoluta guldstandarden för detta. Det är en öppen, leverantörsoberoende standard som gör att du kan samla in Traces (spår), Logs (loggar) och Metrics (mätvärden) utan att låsa upp dig till specifika plattformar som Datadog eller Dynatrace.
I den här guiden bygger vi en komplett, produktionsredo observerbarhetspipeline i .NET 10 – från grundläggande arkitektur till smarta enrichers. När vi är klara är din applikation helt redo att sömlöst pluggas rakt in i verktyg som .NET Aspire Dashboard.
-
Migrera din ASP.NET MVC 4.8 till .NET 10 – En komplett guide
Att migrera en ASP.NET MVC-applikation från gamla .NET Framework 4.8 till det moderna .NET 10 är inte bara en uppgradering – det är ett generationsskifte. Du lämnar det tunga, Windows-bundna IIS-ekosystemet och kliver in i en värld av blixtsnabb prestanda, plattformsoberoende och otroligt ren kod.
Det är sällan en “sök och ersätt”-manöver. För att få ut maximalt av .NET 10 behöver du tänka om kring hur applikationen startar, hur filer hanteras och, framför allt, hur du strukturerar din kod.
Här är en guiden (med kod, arkitekturtips och referenser) för att göra resan smidig och resultatet uppdelat enligt vertikala slices.
-
Flerstegsflöden i .NET: Sekventiella Vyer och Isolerad State Management
Att bygga e-tjänster och flerstegsflöden (wizards) i ASP.NET Core MVC är en vanlig uppgift i företagsapplikationer. Men när ett flöde växer från tre till tio steg blir det snabbt en utmaning att hålla ordning på vyer, specifika valideringsmodeller och tillståndshantering (state management). Om allt sprids ut i generiska mappar tappar utvecklare snabbt överblicken.
Genom att kombinera principer från Vertical Slice Architecture med en strikt sekventiell namngivningsstandard och en robust distribuerad sessionsarkitektur, kan vi skapa en struktur som är självförklarande, högpresterande, extremt underhållsvänlig och redo för produktion i molnet.
-
Från kaos till Clean Code: Tag Helpers och skottsäkert CSRF-skydd i .NET 10
När du kliver in i modern webbutveckling med .NET 10 och ASP.NET Core MVC är det en specifik rad i din
_ViewImports.cshtml-fil som lägger fundamentet för hela din frontend-arkitektur:@addTagHelper *, Microsoft.AspNetCore.Mvc.TagHelpersKort sagt är detta startskottet som aktiverar Tag Helpers i dina Razor-vyer. Utan den raden är alla dina smarta HTML-taggar (som
<a asp-action="...">eller<form asp-controller="...">) bara död text som servern ignorerar.I den här djupdykningen ska vi titta närmare på hur Tag Helpers fungerar under huven, hur du härdar dina applikationer med Anti-Forgery Tokens, och hur du undviker det klassiska produktionsfelet där användare kastas ut ur formulär vid serveromstarter.
-
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).