Programmering

Läsvärt från forskningsfronten

Uppmaningarna från säkerhetsmyndigheter världen över är tydliga: nya system bör byggas i minnessäkra språk. Statistiken talar sitt tydliga språk – majoriteten av allvarliga sårbarheter i systemkod är minnesfel.

För befintlig C/C++-kod handlar det om gradvis förstärkning: sanitizers i CI, fuzzing och att skriva nya moduler i Rust där gränssnitten tillåter.

Siffrorna bakom uppmaningarna är svåra att argumentera emot: både Microsofts och Googles analyser har i åratal landat på att omkring 70 procent av deras allvarliga sårbarheter är minnesfel – buffertöverskrivningar, use-after-free, dubbelfrigöringar. Det är en hel felklass som minnessäkra språk eliminerar per konstruktion, inte genom disciplin.

Snabbguide: versionering och kontrakt

Bra API:er är tråkiga: förutsägbara namn, konsekventa felformat och dokumenterade kontrakt. OpenAPI-specifikationen bör vara källan som både kod och dokumentation genereras från.

Versionera genom addition – nya fält och endpoints – i stället för brytande ändringar. När brytningen är oundviklig: ge konsumenterna lång övergångstid och verktyg för migrationen.

Felhanteringen är där flest API:er avslöjar sin ålder. Ett konsekvent felformat – gärna standarden Problem Details – med maskinläsbara felkoder, begärans-id för felsökning och mänskligt läsbara förklaringar gör skillnaden mellan en integratör som felsöker på minuter och en som öppnar supportärende. Definiera formatet dag ett; att eftermontera det i hundra endpoints gör ingen.

Under huven: konsistensmodeller

Postgres räcker längre än de flesta tror – med JSONB, fulltext och logisk replikering täcker den de flesta behov. Specialdatabaser motiveras först vid extrema krav på skala eller latens.

Förstå CAP-avvägningarna innan du väljer: stark konsistens kostar tillgänglighet vid nätverksproblem. För de flesta affärssystem är det rätt pris att betala.

Börja i rätt ände: åtkomstmönstren, inte funktionslistorna. Hur många skrivningar per sekund, hur ser frågorna ut, vilka svarstider kräver användarupplevelsen och hur mycket data pratar vi om egentligen? De flesta system som “behöver skala” ryms med marginal i en välindexerad Postgres på modern hårdvara – att börja distribuerat är att betala komplexitetspriset innan behovet bevisats.

Veckans verktyg: py-spy och Scalene

Gissningar om prestanda är nästan alltid fel. py-spy låter dig profilera körande processer utan omstart, medan Scalene separerar CPU-, GPU- och minnesanvändning rad för rad.

Börja alltid med en profil innan du optimerar. Nio gånger av tio ligger flaskhalsen i I/O eller en oväntad loop – inte där magkänslan pekar.

py-spys superkraft är att den är ofarlig i produktion: den läser målprocessens minne utifrån utan att injicera kod, så du kan ta en flamegraf av den hängande batchkörningen mitt i natten utan omstart och utan mätbar påverkan. Kommandot py-spy dump som visar alla trådars aktuella stackar har ensamt löst fler mystiska hängningar än något annat verktyg i Python-världen.

Snabbguide: trunk-based development

Små, täta commits mot huvudgrenen med feature flags i stället för långlivade grenar minskar konflikterna dramatiskt. Nyckeln är automatiserade tester som vågar säga nej, och en kultur där trasig main åtgärdas före allt annat.

Börja med att korta ner era pull requests – under 400 rader ändrad kod granskas bevisligen bättre. Kombinera med dagliga integrationer så försvinner de flesta merge-mardrömmarna av sig själva.

Feature flags är mönstrets bärande bjälke och förtjänar egen disciplin. Ofärdig kod kan mergas till main bakom en avstängd flagga, vilket skiljer driftsättning från lansering – koden åker ut kontinuerligt, funktionen slås på när den är redo. Men flaggor åldras dåligt: sätt ett utgångsdatum på varje flagga och städa regelbundet, annars byter ni merge-konflikter mot ett träsk av döda kodvägar.

Att skriva om monoliten från grunden är nästan alltid fel svar. De framgångsrika migrationerna vi ser följer i stället strangler fig-mönstret: ny funktionalitet byggs utanför, gammal flyttas gradvis.

Första steget är alltid detsamma: kartlägg domängränserna. Verktyg som kan analysera beroendegrafer och ändringsmönster i versionshistoriken avslöjar var de naturliga sömmarna finns.

Sätt mätbara mål för varje etapp och fira delsegrar. En migration utan synliga framsteg tappar både budget och entusiasm inom ett halvår.

Asynkron programmering i Rust förvirrar många nykomlingar. Nyckeln är att förstå att en future inte gör någonting förrän den pollas – Rust bygger på lat evaluering, till skillnad från JavaScripts ivriga promises.

Runtimen, oftast Tokio, ansvarar för att schemalägga tasks över trådar. Det förklarar också de ökända Send-felen: din data måste kunna flytta mellan trådar säkert.

Vårt tips: börja med enkla async fn och tokio::spawn, och undvik att blanda blocking-kod i async-kontexter – det är källan till de flesta prestandaproblem.

Systemdesign har blivit det viktigaste ämnet i tekniska intervjuer – och med rätta. I en tid när AI skriver allt mer rutinkod blir förmågan att designa helheter det som skiljer ingenjörer åt.

Grunderna är eviga: lastbalansering, cachning, databasval, konsistensmodeller. Men nya frågor tillkommer, som kostnadsoptimering i molnet och design för AI-arbetslaster.

Bästa sättet att lära sig är att rita. Ta en tjänst du använder dagligen och skissa hur du skulle bygga den – begränsningarna lär dig mer än någon kurs.

Rust har seglat upp som ett verkligt alternativ till C för inbyggda system. Minnessäkerheten utan skräpsamlare gör språket idealiskt för mikrokontrollrar med begränsade resurser.

Med no_std-läget och crates som embedded-hal kan du skriva drivrutiner som är portabla mellan olika chip. Communityt kring embedded Rust växer snabbt och stödet för STM32, ESP32 och RP2040 är i dag moget.

Börja med en Raspberry Pi Pico och boken “The Embedded Rust Book” – på en helg har du en blinkande LED och en god grund att bygga vidare på.