15. April 2024

Brug UUID’er i din database

Internettet bugner med guides omhandlende hvordan du lærer at programmere. Desværre, så er der et kæmpe gab fra begynderguides til de mere avancerede emner. Hvad med de små “cowboy-tricks” som guides ikke lærer dig? Får vi bragt dem på bane, får vi ultimativt bedre IT-løsninger. Jeg kalder dem cowboy-tricks, fordi “best practice”-terminologien ikke rigtig holder særlig længe i IT-branchen: Det der anbefales i dag, kan være yt allerede i morgen.

Eksempel: Man kan stadig finde 20 år gamle PHP-guides på nettet, der instruerer folk i at bruge den uddaterede MD5-hashingalgoritme. Det er lidt trist, når den slags guides ofte er nybegynderes første kontakt med webprogrammering, for så får man ofte den opfattelse, at det er sådan, man gør. Se istedet password_hash().

Programmørfællesskabet Stack Overflow er der, hvor du finder de friskeste tråde omkring forskellige aspekter ved programmering. Finder du de tråde, så læs dem, det er der man virkeligt lærer: Når folk argumenterer for, hvorfor de vælger eller fravælger den løsningsmodel, de eller andre brugere har præsenteret i forumtråden. Og det er måske den bedste hjælp, når vi giver viden videre til andre. Det, der er særligt godt ved StackOverflow, når sitet viser sig fra sin bedste side, er at folk gerne samler årgamle tråde op for at tilføje opdateret viden.

Nå, men tilbage til UUID’erne…

Begyndelsen

Noget af det første du lærer i en guide, er hvordan du sætter din database op, sammen med den programmerings-platform, du nu interesserer dig for. De lærer dig at sætte en ID-kolonne op med fortløbende autonummerering og en primærnøgle, såsom:

ID Navn
1 Anna
2 Gylda
... ...

Det er fundamentet for alle databaseprojekter. Men midt i al simpliciteten, så slipper de fleste guides ret ofte tøjlerne, der hvor man går fra teori til praksis. Og det er et problem, fordi en database, hvor man identificerer de enkelte poster via et fortløbende ID er irriterende besværlig at arbejde med, hvis den skal kombineres med andre datakilder.

Sov godt om natten

Forestil dig, at du er ved at programmere et nyt artikelsystem på en hjemmeside. Du har en tabel i din database med flere tusinde rækker. Fra 1 - 1000. En dag kommer din chef og vil have dig til at kombinere den gamle artikeltabel med en anden tabel, for I har lige fusioneret med et nyt firma. Men der er et problem: Den anden artikeltabel har også rækker fra 1 - 1000.

Løsningen vil være, at de friskeste data gives ID’erne 1001 og fremefter… I mindre setups, hvor data ikke nødvendigvis skal ordnes kronologisk vil det ikke være et problem lige med det samme, men det er alt andet lige en skrøbelig løsning.

For du har jo normaliseret databasen, ikke? ;-) Skal du stadig have sammenhæng i dine data skal poster i evt. afledte tabeller også have det nye fortløbende ID, så det er tungen lige i munden ved kørsel af en dataimport. Du skal være 100% sikker på, at der ikke er dublerede Id’er. Hvis din tabels ID-kolonne har en primærnøgle, så kan du være sikker på, at databaseserveren sender eder og bespottelser i din retning, hvis den importerer et ID, der allerede findes.

Der må da være en lettere metode, der kan sikre din nattesøvn?

UUID’er to the rescue!

UUID’er - Universally Unique Identifier (UUID) - er unikke nøgler på maks. 128 bits længde. De ses ofte repræsenteret som en tekststreng på 32 karakterer hexadecimalt - f.eks 550e8400-e29b-41d4-a716-446655440000, men kan grundet makslængden på 128-bit også repræsenteres udelukkende som heltal. Det gør databaseserveren MariaDB/MySQL f.eks, og det forvirrede mig i starten.

Hvis du er masochist-typen kan du endda repræsentere et UUID binært med 0′er og 1-taller. Men så er vi vist ude i selvpineri, det kan jeg ikke se nogen fornuftig idé i ;-) I Assembly begyndte man også at bruge hexadecimal notation, fordi det var kortere og nemmere at arbejde med end binær notation.

Intet sammenfald

Givet en 128-bit størrelse, så er det meget usandsynligt, at to genererede nøgler nogensinde vil være ens. Wikipedia nævner i et afsnit om UUID’er, at blandt 103 trillioner generede UUIDv4-strenge, så er sandsynligheden for et nøgle-sammenfald 1:1.000.000.000 (1 milliard).

Ergo kan vi bestemt godt bruge dem som vores fikspunkt for datafletning. Du får en databasepost med en kolonne hvor data, der refereres til, altid er unikt og det bliver yderligere en fordel og et absolut must, hvis du en dag skal arbejde med data, der befinder sig i et servercluster, hvor forskellige servere udveksler data med hinanden (aka. distribuerede data).

Du kan også med fordel bruge UUID’er, når data eksporteres ud i et andet format, såsom JSON eller XML, fordi du kan referere tilbage til den oprindelige post. Det kan der så være sikkerhedsmæssige overvejelser til, at man IKKE vil gøre, men det er op til den, der implementerer IT-løsningen.

Lidt slutovervejelser

Måske synes du det er overkill at bruge UUID’er i dit projekt, men det er altid fint at tænke langsigtet, også selvom dine projekter starter med at være små og afgrænsede. Selvfølgelig skal du overveje om det er umagen værd, og der kan være ydelsesmæssige ulemper ved at bruge UUID’er som primærnøgle, fordi værdien 4 gange større, end hvis du vælger at indeksere en kolonne med heltal (typisk med Id-kolonnen) og det er også omstændigt at referere et UUID, hvis du ofte sammenkæder resultater på tværs af flere tabeller. Men om det er et ydelsestab, der er til at bære eller ej, det kan kun en test afsløre.

Jeg plejer at helgardere ved at bruge både en autonummereret ID-kolonne og en UUID-kolonne, så er både jeg og databasen glad, for så er der forskellige muligheder for at referere og indeksere samme datapost.

For at opsummere hele opslaget: Brug kun et fortløbende heltal som ID til at referere til poster internt i databasen. Det id bør på intet tidspunkt eksponeres ude i det fri. Skal du referere til en databasepost ifm. din programmering, så benyt altid det oprettede UUID.

Kildelinks

Wikipedia: Universally unique identifier
Programmørforum: Stack Overflow
Udvikleren.dk: Normalisering baseret på primærnøgler

11. April 2024

Xbox360-butikken lukker

Microsoft har annonceret, at de lukker den digitale store på Xbox360 ned i juli 2024. Så har du nogle spil, du skal hente ned, inden det er for sent, så er det nok snart, det skal være. Ellers så må du en tur på retromarkedet efter de fysiske udgaver :)

Ejere af Xbox Series S og X kan stadig hente XBox360-kompatible spil efter den dato.

Okay, Xbox 360′eren er gammel efterhånden. Men det er stadig en vild maskine. Jeg købte selv en et par måneder efter launch. Det var nok i Jan-Feb ‘06, og havde den længe.

Den fik den der Red Ring of Death-fejl pga. overophedning efter nogle år - men egentlig ret sent i dens livscyklus. Det var et kendt problem, og Microsoft byttede den da også uden brok til en Xbox360 Elite. Mange fede timer gik med den. Særligt: Mass Effect-serien, Halo, Gears of War og GTA V var nogle af de spil, jeg spillede mest.

So long, Xbox 360 - it’s been a blast!

Kilder

Microsoft: The Xbox 360 Store Will Close July 2024

8. April 2024

Canadisk teleselskab lovede 1 års cloud storage, indhold slettes efter 61 dage

Webmediet Ars Technica skriver, at det canadiske teleselskab Bell oprindeligt lovede abonnenter på deres Fibe-service, at de kunne lagre en video i 365 dage på deres PVR cloudservice. Det vil de pr. 1. maj (2024) skære ned til 61 dage.

Selvom dette finder sted i Canada, så er det et eksempel på, hvordan en serviceydelse kan ændre vilkår lynhurtigt. Det er ikke usandsynligt at noget lignende også vil ske - eller er sket - i Danmark. Derfor, hvis du er den heldige ejer af en harddiskoptager, så hold endelig fast på den.


Serviceøkonomien er det vilde vesten. Jeg prøver indimellem at hive eksempler frem her på bloggen, som jeg finder ude på det store internet. Formålet er, at få dig som læser til at fundere over, om det nu er klogt at digitalisere alting, eller om vi skal holde fast i noget af det gamle. Du kan finde det hele i kategorien “Serviceøkonomien”.

Kildelinks

Ars Technica: Telecom says it’s deleting DVR recordings over 2 months old starting May 1

7. April 2024

Softwaresikkerhed i OSS-projekter

Open Source-miljøet står for mig som noget smukt, hvor mennesker arbejder sammen på tværs af forskelle. Det er “the world done right”, når det fungerer. Fundamentet for Open Source er samarbejde og tillid til hinanden. Det må ikke svækkes. Nogensinde.

Den skærende kontrast er til OSS, at verden udenfor desværre i mange henseender alt for ofte præges af konflikter, konkurrencementalitet og magtkampe. Konkurrencementaliteten er så indgroet et samfundselement, at vi nogle gange knapt opdager, når vi bliver udsat for den.

Det lykkes - for det meste - projektejerne og bidragsyderne til Open Source Software (OSS) at parkere den slags ude i den virkelige verden, og fokusere på den fælles opgaveløsning. Det nylige Supplychain-angreb på xz-projektet kalder dog på, at der skal hankes op i sikkerheden helt generelt i OSS-projekter. Men hvordan?

I tilfældet med xz-projektet var bagdøren ikke bare et enkeltstående “hit-and-run” commit, men tilsyneladende metodisk orkestreret af en betroet bidragsyder, der havde bidraget til projektet gennem en lang periode.

Hændelsen er forfærdentlig, det er mig ubegribeligt, at nogen aktivt forsøger at destabilisere det gode, tillidsbaserede samarbejde. Men det er et bevis på, at virkeligheden har indhentet Open Source-miljøet. OSS-miljøet må stå sammen, reagere, og vise, at man ikke accepterer folk, der vil underminere frisindet og idylen.

Spørgsmålet er, hvordan man bedst forener frivillig, interessedrevet udvikling med et øget fokus på sikkerhed.

Mange proprietære, closed source projekter indeholder Open Source-komponenter. Netop fordi OSS bruges i så stort omfang, også i lukkede miljøer betyder, at alle burde have et incitament for, at OSS-miljøet kommer styrket ud af det her.

For at blive konkret - hvad er der egentlig af muligheder? Et sted at starte, kunne være at få integreret kodeskanningsværktøjer i sit workflow, også i små og mellemstore projekter. Selvom dit projekt lige nu er et lille hyggeprojekt, så kan den slags hurtigt gribe om sig.

Enter, OWASP Foundation. OWASP er en non-profitorganisation, der arbejder for at højne sikkerheden i OSS-projekter - og de har lavet en fin liste over åbne og closed-source kodescanningsprojekter.

Listen findes her:
https://owasp.org/www-community/Source_Code_Analysis_Tools

5. April 2024

Star Wars: Tales of the Empire

“Why do you seek Imperial favor?”.

Åbningssekvensen med Admiral Thrawn og Morgan Elsbeth giver kuldegysninger på den absolut fedeste mulige måde, for det er Lars Mikkelsens ikoniske stemme, du hører.

Spænd sikkerhedsselen, for traileren er måske den mest hæsblæsende Star Wars-trailer til dato. Det bliver et gensyn med mange gamle kendinge. Jeg tror det bliver rigtig fedt, det her, men døm selv: