{"version":"https://jsonfeed.org/version/1.1","title":"Engineer — Portefølje","home_page_url":"https://engineer.company/da/","feed_url":"https://engineer.company/da/feed.json","description":"Engineer ApS — softwareudvikling \u0026 IT-rådgivning i København, Danmark. En portefølje af dokumenterede ingeniørresultater inden for software, data, cloud og IT.","language":"da","items":[{"id":"https://engineer.company/da/portfolio/increased-brand-popularity-by-200x-through-successful-brand-1/","url":"https://engineer.company/da/portfolio/increased-brand-popularity-by-200x-through-successful-brand-1/","title":"Har øget brandets popularitet 200 gange gennem succesfuld brandudvikling på tværs af offline- og onlineplatforme.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e Engineer ApS var en helt ny konsulentvirksomhed med reel teknisk dybde og næsten ingen, der havde hørt om den. Det er en bestemt slags frustrerende: kunnen er der, arbejdet ville være godt, men intet af det betyder noget, hvis de kunder og partnere, der ville have det, ikke ved, man findes. En ung virksomhed skal ses, før den kan vinde noget som helst.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eOpgave.\u003c/strong\u003e Opgaven var at opbygge et brand, folk faktisk ville genkende — på tværs af både offline- og onlinesiden — og at omsætte virksomhedens tekniske troværdighed til synlig tilstedeværelse på markedet frem for at lade den ligge som en velbevaret hemmelighed.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eHandling.\u003c/strong\u003e Brandet blev bygget bevidst og holdt konsistent. Det startede med en klar identitet — en tone, et visuelt sprog og en portefølje, der førte an med konkrete tekniske resultater frem for det vage \u0026ldquo;vi skaber værdi\u0026rdquo;-sprog, alle andre bruger. Så kørte det på tværs af de kanaler, der betyder noget for den slags virksomhed — websitet, LinkedIn, GitHub, fysiske arrangementer — med hvert kontaktpunkt, der sagde det samme frem for hver at drive af på sin egen måde. Den røde tråd var at føre an med rigtige case‑studier og rigtige resultater, så troværdigheden var noget, man kunne se bevis for, ikke bare en påstand.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResultat.\u003c/strong\u003e Brandets rækkevidde voksede omkring 200 gange på tværs af offline- og onlineplatforme — en ukendt nytilkommen blev til noget, folk faktisk genkendte. Og det var ikke forfængelig rækkevidde; synligheden begyndte at producere en stabil strøm af indgående henvendelser og muligheder, der simpelthen ikke havde været der før.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/da/portfolio/drove-brand-engagement-and-loyalty-by-100-through-2/","url":"https://engineer.company/da/portfolio/drove-brand-engagement-and-loyalty-by-100-through-2/","title":"Har øget brandengagement og -loyalitet med 100 % gennem analyse af markedstendenser og indsigt i forbrugeradfærd.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e Efterhånden som synligheden klatrede, nåede Engineer ApS flere mennesker — men engagementet var tyndt. Folk lagde mærke til det og gik videre; den tidlige interesse blev ikke til relationer, der holdt. Rækkevidde uden engagement er bare støj, og brandet lavede støj mere end forbindelser.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eOpgave.\u003c/strong\u003e Målet var at uddybe engagementet og loyaliteten, og gøre det ved faktisk at kigge på, hvad markedet og publikummet reagerede på, frem for at stole på mavefornemmelse.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eHandling.\u003c/strong\u003e Så brandet blev datainformeret i stedet for intuitionsstyret. Det betød at kigge på markedstendenserne og på, hvordan publikummet faktisk opførte sig på tværs af kanalerne — ikke hvad nogen antog, de ville kunne lide, men hvad de påviseligt engagerede sig i. Det afslørede de emner og formater, der trak ægte opmærksomhed, og indholdet og opsøgningen blev styret mod dem. Den vigtige del var at stramme loopet: se, hvad der landede, udgiv mere af den form næste gang, og lad hver cyklus være en smule bedre rettet end den forrige.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResultat.\u003c/strong\u003e Engagement og loyalitet blev fordoblet — en forbedring på 100 % — med et publikum, der kom tilbage og engagerede sig frem for at kigge én gang og gå, og markant stærkere relationer til potentielle kunder og partnere. Brandet holdt op med at udsende ud i tomrummet og begyndte at opbygge noget, der kom tilbage.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/da/portfolio/designed-a-comprehensive-infrastructure-framework-for-dtu-impacting-3/","url":"https://engineer.company/da/portfolio/designed-a-comprehensive-infrastructure-framework-for-dtu-impacting-3/","title":"Har designet en omfattende infrastrukturramme for DTU, der berører 14 afdelinger, med fleksible moduler, samlede datapipelines og strukturerede supportstrategier med henblik på langsigtet udbredelse.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e På et forskningsinstitut bestående af 14 forskellige forskningsgrupper arbejdede hver gruppe med forskellige datakilder, formater, skalaer og softwareværktøjer. Den tekniske ekspertise og de tilgængelige IT‑ressourcer varierede meget på tværs af grupperne. Mens nogle få havde formået at skabe og udrulle skræddersyede IT‑løsninger, kæmpede mange med kompleksiteten af deres datainfrastrukturbehov, hvilket tog værdifuld tid og fokus fra deres kerneforskning.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eOpgave.\u003c/strong\u003e Opgaven var at udtænke en løsning, der ville give forskerne mulighed for at fokusere på deres videnskabelige arbejde frem for IT‑udfordringer. Målet var at designe og implementere en skalerbar, institutdækkende datainfrastruktur, der kunne rumme de brede og forskelligartede behov hos størstedelen af forskningsgrupperne.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eHandling.\u003c/strong\u003e En robust og fremtidssikret infrastrukturplan blev udviklet, der balancerede fleksibilitet og standardisering. Planen skitserede nøglekomponenter såsom modulær arkitektur, integrationsveje for forskellige datakilder, brugervenlige grænseflader tilpasset varierende tekniske niveauer samt skalerbare lagrings- og behandlingsløsninger. Den omfattede også strategier for onboarding, support og governance for at sikre udbredelse og bæredygtighed.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResultat.\u003c/strong\u003e Den resulterende infrastrukturplan var både teknisk solid og strategisk afstemt med instituttets forskningsmål. Den forenede visionen for datahåndtering på tværs af organisationen, gav en klar vej til at reducere IT‑byrden på forskerne og lagde fundamentet for et fælles, effektivt og fremtidsklart forskningsdatamiljø. Planen blev vel modtaget for sin inklusivitet, klarhed og tilpasningsevne og satte en stærk retning for instituttets transformation af datainfrastrukturen.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/da/portfolio/engineered-hourly-electricity-consumption-aggregation-pipeline-in-python-4/","url":"https://engineer.company/da/portfolio/engineered-hourly-electricity-consumption-aggregation-pipeline-in-python-4/","title":"Har udviklet en pipeline til timebaseret aggregering af elforbrug i Python / SQL / Bash + Jq, der opnår 180 ms for 30‑dages datasæt på tværs af heterogene JSONL‑kilder.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e Virksomheden behandler store mængder heterogene eldata fra flere datakilder, hver med sin egen rapporteringsfrekvens — fra timeintervaller til 15‑minutters intervaller og i nogle tilfælde uregelmæssige tidsstempler. Denne variabilitet gør det udfordrende at skabe et sammenhængende, sammenligneligt datasæt. For at understøtte præcis energianalyse skal disse data normaliseres til konsistente timeforbrugsværdier, aggregeret pr. zone.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eOpgave.\u003c/strong\u003e Målet var at tage rå event‑data fra et historisk datasæt (i JSONL‑format) og konvertere det til timeafstemte elforbrugstal, struktureret som én række pr. time og pr. zone. Konkret indebar opgaven at afstemme tidsstemplede data til strikse timeintervaller, aggregere den samlede elproduktion inden for hvert interval, indregne grænseoverskridende udveksling ved at lægge import til og trække eksport fra, og udskrive de endelige værdier i et struktureret, skalerbart format. Løsningen skulle desuden være effektiv nok til at skalere over lange tidsvinduer (30+ dage) og på tværs af flere lande/zoner.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eHandling.\u003c/strong\u003e Tre forskellige varianter af løsningen blev implementeret med henholdsvis Python, JQ (til JSON‑behandling på kommandolinjen) og SQL, hver optimeret til forskellige kontekster. Python blev valgt for sin fleksibilitet og evne til effektivt at håndtere in‑memory‑transformationer: en pipeline, der parser JSONL‑filerne, resampler tidsserien til timeintervaller, aggregerer produktion og beregner nettoelforbrug (produktion + import − eksport) og eksporterer resultaterne. JQ gav en hurtig løsning med minimale afhængigheder, og i PostgreSQL blev dataene importeret, normaliserede tabeller oprettet og en række SQL‑forespørgsler skrevet. For at vurdere ydeevnen blev hver løsning benchmarket med både 1‑dags og 30‑dages datasæt.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResultat.\u003c/strong\u003e Python‑implementeringen viste sig som den hurtigste og mest skalerbare løsning og gennemførte 1‑dags databehandling på blot 34 ms og 30‑dages datasættet på 180 ms. Det bekræftede egnetheden til større tidsvinduer med sub‑sekund‑ydeevne og gav samtidig klar, vedligeholdelig kode, der let kunne udvides til flere zoner eller integreres i en ETL‑pipeline.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/da/portfolio/accelerated-geographical-data-pipeline-performance-by-50x-by-5/","url":"https://engineer.company/da/portfolio/accelerated-geographical-data-pipeline-performance-by-50x-by-5/","title":"Har øget ydeevnen af geografiske datapipelines med 50 gange ved at forbedre SQL‑programmering og datamodellering på tværs af PostgreSQL, MS SQL og Google Cloud BigQuery.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e Organisationen oplevede betydelige forsinkelser i behandlingen af store mængder geografiske data, hvilket påvirkede effektiviteten af datadrevne beslutningsprocesser og analytisk rapportering.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eOpgave.\u003c/strong\u003e Målet var at optimere den geografiske datapipeline for at forbedre ydeevnen og reducere behandlingstiden, så dataanalyse kunne udføres mere effektivt og i realtid.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eHandling.\u003c/strong\u003e De eksisterende SQL‑programmerings- og datamodelleringsstrukturer på tværs af PostgreSQL, MS SQL og Google Cloud BigQuery blev analyseret grundigt, hvilket afslørede flaskehalse relateret til ineffektive indekseringsstrategier, suboptimale forespørgsler og manglende constraints. For at afhjælpe dette blev datamodellerne redesignet og partitioneringsstrategier indført, avancerede indekseringsteknikker (B‑tree og GiST i PostgreSQL, filtrerede indeks i MS SQL og clustering i BigQuery) anvendt, komplekse SQL‑forespørgsler optimeret ved at refaktorere subqueries og reducere joins, samt data integrity‑constraints som foreign keys og check‑constraints indført for at sikre konsistens uden at gå på kompromis med ydeevnen.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResultat.\u003c/strong\u003e Disse omfattende optimeringer accelererede den geografiske datapipelines ydeevne 50 gange og reducerede databehandlingstiden markant. Forbedringen muliggjorde realtidsanalyse, styrkede rapporteringskapaciteten og gav interessenterne rettidige, datadrevne indsigter, hvilket i sidste ende bidrog til mere velfunderede strategiske beslutninger.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/da/portfolio/improved-geographical-map-application-performance-by-10x-through-6/","url":"https://engineer.company/da/portfolio/improved-geographical-map-application-performance-by-10x-through-6/","title":"Har forbedret geografiske kortapplikationers ydeevne med 10 gange gennem en strategisk databaseovergang fra MSSQL til PostgreSQL, hvilket har optimeret behandlingen og datasikkerheden.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e Organisationens geografiske kortapplikation, der understøttede realtids‑spatialforespørgsler for mange brugere, oplevede alvorlige flaskehalse i ydeevnen. Latens ved rendering af kortlag og forespørgsler på lokationsbaserede data påvirkede både brugeroplevelsen og backend‑tjenesternes pålidelighed. Systemet byggede på en ældre Microsoft SQL Server‑database (MSSQL) uden native geospatial indeksering.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eOpgave.\u003c/strong\u003e At forbedre kortapplikationens ydeevne, skalerbarhed og sikkerhed med det specifikke mål at reducere forespørgselslatensen og øge gennemløbet for spatiale operationer.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eHandling.\u003c/strong\u003e En strategisk databasemigrering fra MSSQL til PostgreSQL med PostGIS‑udvidelsen blev ledet for at muliggøre native geospatial understøttelse. Et nyt skema optimeret til spatiale data blev designet med GiST- og SP‑GiST‑indeks på geometri- og geografikolonner, strikse foreign key- og check‑constraints defineret, over 50 millioner spatiale records migreret via ETL‑pipelines med transformation til nye SRID‑standarder (EPSG:4326), PostgreSQL‑konfigurationsparametre (work_mem, effective_cache_size) tunet og role‑based access control (RBAC) og row‑level security implementeret.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResultat.\u003c/strong\u003e En 10‑dobbelt forbedring i spatial forespørgselsydeevne blev opnået, og den gennemsnitlige svartid reduceret fra 2,5 sekunder til under 250 millisekunder. Backend‑CPU‑belastningen faldt med 65 %, og systemtilgængeligheden blev bedre i spidsbelastningsperioder. Sikkerheden blev også styrket med granulære adgangspolitikker og valideringsconstraints, hvilket reducerede risikoen for korruption af spatiale data.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/da/portfolio/resolved-1-000-issues-in-geographical-data-and-7/","url":"https://engineer.company/da/portfolio/resolved-1-000-issues-in-geographical-data-and-7/","title":"Har løst 1.000 problemer i geografiske data og tidsseriedata ved hjælp af GDAL, ArcGIS, PostGIS, Mapbox, QGIS, SQL (PL/pgSQL, Transact‑SQL) og Bash, hvilket har sikret behandling af big data i høj kvalitet.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e Under arbejdet på et storstilet geospatialt analyseprojekt stødte teamet på talrige uoverensstemmelser og anomalier i de geografiske datasæt og tidsseriedatasæt. Disse problemer påvirkede nøjagtigheden af spatiale analyser og beslutningsværktøjer på tværs af flere afdelinger.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eOpgave.\u003c/strong\u003e Ansvaret var at identificere, løse og optimere over 1.000 datakvalitetsproblemer i disse komplekse datasæt for at sikre integriteten og ydeevnen af downstream‑applikationer og visualiseringer.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eHandling.\u003c/strong\u003e Spatiale fejl blev systematisk diagnosticeret og rettet med en kombination af værktøjer, herunder GDAL, QGIS og ArcGIS, og automatiserede workflows implementeret med Bash‑scripting til tilbagevendende datarensning. PostGIS blev brugt til avancerede spatiale forespørgsler og spatial indeksering, og robuste procedurer skrevet i PL/pgSQL og Transact‑SQL til at håndtere og transformere både geografiske og tidsmæssige data i PostgreSQL- og SQL Server‑databaserne. Derudover blev de rensede data integreret i interaktive visualiseringer med Mapbox.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResultat.\u003c/strong\u003e Gennem denne indsats blev over 1.000 kritiske problemer løst, hvilket markant forbedrede datanøjagtigheden og behandlingshastigheden. Det bidrog direkte til en 35 % reduktion i køretider for spatiale forespørgsler og muliggjorde mere pålidelige spatiale analyser. Arbejdet sikrede, at data af høj kvalitet konsekvent var tilgængelige til analyse og rapportering til støtte for strategiske beslutninger på tværs af organisationen.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/da/portfolio/designed-implemented-and-administered-6-etl-elt-pipelines-8/","url":"https://engineer.company/da/portfolio/designed-implemented-and-administered-6-etl-elt-pipelines-8/","title":"Har designet, implementeret og administreret 6 ETL/ELT‑pipelines med Google BigQuery, MSSQL, PostgreSQL, shell‑scripting, PL/pgSQL og Transact‑SQL og integreret data til effektiv behandling via Python API.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e Organisationen havde behov for at konsolidere og behandle store mængder strukturerede data fra et fjernt data warehouse bag en IPSec VPN. Disse data var afgørende for interne analyse‑dashboards og eksterne Python API\u0026rsquo;er brugt af kunder og partnere.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eOpgave.\u003c/strong\u003e Målet var at designe, implementere og vedligeholde et sæt robuste og automatiserede ETL/ELT‑pipelines til sikkert at hente, transformere og indlæse data i Google BigQuery med sikring af datanøjagtighed, ydeevne og skalerbarhed.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eHandling.\u003c/strong\u003e 6 end‑to‑end ETL/ELT‑pipelines blev designet, implementeret og administreret på tværs af Google BigQuery, MSSQL, PostgreSQL, shell‑scripting, PL/pgSQL og Transact‑SQL. Sikre forbindelser til en fjernserver bag en IPSec VPN blev etableret, download af komprimerede dataarkiver (Parquet, CSV og .bak) planlagt, Bash- og Python‑scripts udviklet til at udtrække og klassificere filer, .bak‑filer gendannet i en lokal MSSQL Server‑instans, strukturerede data indlæst i staging‑skemaer med bcp, psql og SSIS, modulære PL/pgSQL- og T‑SQL‑procedurer skrevet til rensning og berigelse og upload og skema‑mapping til Google BigQuery automatiseret via bq CLI og Python‑baseret dataindtagelse.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResultat.\u003c/strong\u003e Disse automatiserede pipelines reducerede den manuelle indsats og behandlingstid markant — fra over 3 timers manuelt arbejde til under 20 minutter end‑to‑end — og forbedrede dataaktualiteten fra ugentlig til daglig synkronisering. Python‑API\u0026rsquo;erne, der forbrugte dataene, opnåede en 30 % ydeevneforbedring, og den øgede synlighed hjalp forretningsanalytikere med at levere hurtigere indsigter. Løsningen forbliver skalerbar og udvidelig til nye datakilder, efterhånden som forretningen vokser.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/da/portfolio/developed-and-launched-the-company-s-first-observability-9/","url":"https://engineer.company/da/portfolio/developed-and-launched-the-company-s-first-observability-9/","title":"Har udviklet og lanceret virksomhedens første observability‑dashboard, der leverer indsigt i systemets ydeevne i realtid og datavisualisering på det store kontor‑TV.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e Virksomheden havde udfordringer med at overvåge systemets ydeevne i realtid, hvilket ofte førte til forsinket incidenthåndtering og reduceret indblik i infrastrukturens tilstand. Der fandtes ingen central løsning, hvor teams kunne få indsigt i driftsmetrikker.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eOpgave.\u003c/strong\u003e Opgaven var at udvikle en løsning, der ville gøre det muligt for både tekniske og ikke‑tekniske interessenter at overvåge centrale systemmetrikker i realtid med fokus på tilgængelighed, klarhed og proaktiv fejlopsporing.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eHandling.\u003c/strong\u003e Virksomhedens første observability‑dashboard blev designet og implementeret og indsamlede alle væsentlige systemmetrikker — CPU, RAM, HDD, temperatur med mere — fra fjerne Linux‑servere via SSH, og selv Docker‑containere blev overvåget på denne måde. Senere blev en anden version designet og implementeret med Grafana og Prometheus til mere avanceret visualisering. Samarbejde med DevOps- og engineering‑teams identificerede kritiske metrikker, datapipelines blev konfigureret til at indsamle og behandle ydeevnemetrikker, og dashboardet udrullet på en stor kontor‑TV‑skærm for maksimal synlighed. Alarmering ved overskridelse af tærskler blev også integreret.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResultat.\u003c/strong\u003e Dashboardet forbedrede markant systemets gennemsigtighed og responstiden på driftsproblemer. Teams kunne opdage og løse incidents 40 % hurtigere. Det fremmede også en kultur af fælles ejerskab over systemets tilstand ved at gøre ydeevnedata tilgængelige for alle på kontoret, hvilket i sidste ende bidrog til et mere stabilt og effektivt produktionsmiljø.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/da/portfolio/delivered-8-power-bi-projects-with-comprehensive-manuals-10/","url":"https://engineer.company/da/portfolio/delivered-8-power-bi-projects-with-comprehensive-manuals-10/","title":"Har leveret 8 Power BI‑projekter med omfattende manualer, hvor Microsoft Power BI‑værktøjer er integreret med NodeJS API og Python FastAPI for effektiv dataanalyse og visualisering.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e Organisationen havde behov for dynamiske, visuelle indsigter i komplekse datasæt om elnettets ydeevne og geografisk fordeling for at understøtte beslutninger på tværs af tekniske og strategiske teams.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eOpgave.\u003c/strong\u003e At udvikle interaktive dashboards og rapporteringsløsninger, der effektivt kunne præsentere både realtids- og historiske geografiske og elektriske data, så interessenter hurtigt kunne identificere tendenser, anomalier og nøgletal.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eHandling.\u003c/strong\u003e Microsoft Power BI blev integreret med en skræddersyet backend baseret på NodeJS API og Python FastAPI for at strømline dataindtagelse, transformation og visualisering. Dashboards blev designet og implementeret med kortvisualiseringer, målinger af energiforbrug, sporing af nedbrud og indikatorer for neteffektivitet, og genanvendelige skabeloner og detaljeret dokumentation udviklet for at understøtte skalerbarhed og brugervenlighed.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResultat.\u003c/strong\u003e 8 dataanalyseprojekter blev leveret, hvilket forbedrede effektiviteten af rapportgenerering med 60 % og gjorde det muligt for tværfaglige teams at træffe hurtigere, datadrevne beslutninger. Interessenterne rapporterede en markant øget forståelse af den regionale elektriske ydeevne og nøjagtigheden af ressourceplanlægningen.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/da/portfolio/released-500-electricity-and-gis-data-analysis-reports-11/","url":"https://engineer.company/da/portfolio/released-500-electricity-and-gis-data-analysis-reports-11/","title":"Har udgivet 500 rapporter om analyse af el- og GIS‑data, hvor jeg har anvendt dybdegående forskning og fejlfinding for at sikre nøjagtige geografiske og tidsmæssige big data‑indsigter.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e Teamet håndterede enorme datasæt genereret af smart‑metre installeret på tværs af flere geografiske regioner. Disse smart‑metre producerede granulære tidsserie‑data om elforbrug, som blev brugt af energianalytikere, ingeniører og regionale planlæggere til drifts- og strategiske beslutninger.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eOpgave.\u003c/strong\u003e Ansvaret var at producere analytiske rapporter af høj kvalitet, gennemsigtige og reproducerbare, som kunne afdække mønstre i energiforbruget, opdage anomalier og identificere regionale forbrugstendenser, samtidig med at ikke‑tekniske interessenter let kunne fortolke og genbruge resultaterne.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eHandling.\u003c/strong\u003e Over 500 dybdegående dataanalyserapporter blev oprettet og leveret, med ren SQL til al dataudtræk, transformation og analyse direkte i cloud‑baserede miljøer som PostgreSQL og BigQuery. Dataene omfattede geolokationskoordinater, meter‑ID\u0026rsquo;er, tidsstemplet energiforbrug og miljømetadata. SQL‑scripts benyttede CTE\u0026rsquo;er, window functions, subqueries og geospatiale joins for skalerbar og effektiv behandling. Hver rapport indeholdt annoteret SQL‑kode, så kolleger fuldt ud kunne reproducere og revidere forskningen, og fejlfindingsnoter blev tilføjet og almindelige datakvalitetsproblemer dokumenteret med anbefalede håndteringsprocedurer.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResultat.\u003c/strong\u003e Rapporterne blev en standardreference på tværs af afdelinger og hjalp med regional load balancing, planlægning af energieffektivitet og anomalidetektion. Ved at sikre fuld gennemsigtighed og reproducerbarhed hjalp det med at styrke interessenternes tillid til dataene, og arbejdet bidrog til mere præcise prognosemodeller og en 10‑15 % forbedring af driftsplanlægningens effektivitet.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/da/portfolio/architected-created-and-managed-100-postgresql-ms-sql-12/","url":"https://engineer.company/da/portfolio/architected-created-and-managed-100-postgresql-ms-sql-12/","title":"Har arkitekteret, oprettet og administreret 100 data warehouse‑databaser i PostgreSQL, MS SQL og Google BigQuery med primært GIS- og tidsseriedata og optimeret ydeevne og skalerbarhed.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e I en hurtigt voksende teknologivirksomhed var der et kritisk behov for at oprette, administrere og optimere en bred portefølje af over 100 databaser på tværs af PostgreSQL, Microsoft SQL Server og Google BigQuery. Disse databaser håndterede primært komplekse datasæt, herunder GIS‑data (spatiale koordinater og lokationsbaseret analyse) og tidsseriedata (sensoraflæsninger, logs og realtidsmetrikker). Den eksisterende infrastruktur havde udfordringer med skalerbarhed, forespørgselsydeevne og datakonsistens, efterhånden som datamængden voksede eksponentielt.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eOpgave.\u003c/strong\u003e Det primære mål var at designe, implementere og administrere et skalerbart data warehouse‑økosystem med høj ydeevne skræddersyet til GIS- og tidsseriedata. Det indebar at håndtere flaskehalse i komplekse spatiale og tidsbaserede forespørgsler, sikre skalerbarhed og omkostningseffektivitet og samarbejde med tværfaglige teams om at afstemme databasedesign med forretningsbehov.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eHandling.\u003c/strong\u003e Skalerbare arkitekturer blev designet med normaliserede og denormaliserede skemaer til PostgreSQL og SQL Server, spatial indeksering (PostGIS) og tidsseriepartitionering udnyttet samt BigQuerys tidspartitionerede og clustrede tabeller. Optimeringsstrategier som indeksering, materialized views og caching blev indført, datakomprimering og kolonnelagring anvendt i BigQuery og best practices for GIS- og tidsseriedatamodellering dokumenteret til fremtidige projekter.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResultat.\u003c/strong\u003e Initiativerne førte til betydelige forbedringer: svartider for GIS- og tidsseriedata faldt med 40‑60 %, automatiseret overvågning reducerede nedetid med 50 %, og standardiserede processer øgede produktiviteten. Den optimerede infrastruktur gjorde det muligt for virksomheden at lancere nye datadrevne produkter og opfylde krav om data governance og regulatorisk compliance — hvilket styrkede organisationens evne til at håndtere komplekse datamæssige udfordringer.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/da/portfolio/designed-deployed-and-maintained-10-postgresql-and-ms-13/","url":"https://engineer.company/da/portfolio/designed-deployed-and-maintained-10-postgresql-and-ms-13/","title":"Har designet, idriftsat og vedligeholdt 10 PostgreSQL- og MS SQL‑servere på Ubuntu Linux VPS og sikret optimal serverydeevne og pålidelighed.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e Som DevOps‑ingeniør i en mellemstor teknologivirksomhed var opgaven at administrere og optimere databaseinfrastrukturen til støtte for en voksende brugerbase og forretningskritiske applikationer. Organisationen var stærkt afhængig af PostgreSQL og Microsoft SQL Server og krævede høj tilgængelighed, skalerbarhed og sikkerhed.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eOpgave.\u003c/strong\u003e Det primære ansvar var at arkitektere, udrulle, konfigurere og vedligeholde 10 PostgreSQL- og MS SQL Server‑instanser i Ubuntu Linux VPS‑miljøer med optimal ydeevne, robuste sikkerhedsprotokoller og proaktiv overvågning, samt at skalere infrastrukturen til fremtidig vækst uden at gå på kompromis med omkostninger og compliance.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eHandling.\u003c/strong\u003e PostgreSQL 14 og MS SQL Server 2019 blev installeret og konfigureret på Ubuntu 20.04 LTS, automatiserede backups sat op med pg_dump og SQL Server Agent‑jobs med retention og offsite‑lagring, og serverkonfigurationer optimeret (hukommelsesallokering, query caching, connection pooling). Overvågning blev implementeret med Prometheus og Grafana, regelmæssig patching af databaser og OS udført, firewalls (UFW) og RBAC konfigureret og disaster recovery‑procedurer dokumenteret, herunder point‑in‑time‑gendannelse og failover.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResultat.\u003c/strong\u003e 99,9 % oppetid blev opnået på tværs af alle 10 databaseservere, svartider forbedret med 30 % gennem konfigurationstuning og indeksoptimering, manuelt vedligeholdelsesarbejde reduceret med 50 % via automatisering (over 10 timer om måneden frigjort) og infrastrukturen skaleret til at understøtte en 40 % stigning i brugertrafik uden servicetab — hvilket bidrog til 20 % omsætningsvækst i det følgende kvartal. CTO\u0026rsquo;en anerkendte implementeringen af sikkerheds‑best‑practices, der forhindrede potentielle databrud.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/da/portfolio/enhanced-data-security-by-implementing-1-000-rbac-14/","url":"https://engineer.company/da/portfolio/enhanced-data-security-by-implementing-1-000-rbac-14/","title":"Har forbedret datasikkerheden ved at implementere 1.000 RBAC‑regler for udviklere, applikationsinstanser, PostgreSQL, MS SQL og andre Linux‑servere for at forhindre uautoriseret adgang; dokumenteret med Ansible‑automatisering.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e Organisationen havde behov for at styrke adgangskontrollen på tværs af flere systemer, herunder udviklermiljøer, applikationsinstanser, PostgreSQL, MS SQL og Linux‑servere. Selvom den underliggende RBAC‑model var enkel, lå udfordringen i at håndtere over 1.000 individuelle regler for forskellige brugerroller og systemkrav uden at introducere kompleksitet.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eOpgave.\u003c/strong\u003e At implementere en skalerbar RBAC‑løsning ved at definere og håndhæve over 1.000 regler for adgangskontrol. Det indebar at mappe rettigheder til specifikke roller (udviklere, applikationsinstanser, databaseadministratorer) og at anvende reglerne konsistent på tværs af alle systemer, samt at dokumentere reglerne og automatisere deres udrulning.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eHandling.\u003c/strong\u003e Tilgangen fokuserede på at skabe en enkel, modulær RBAC‑struktur, med rettigheder brudt ned i klare, genanvendelige kategorier (f.eks. \u0026ldquo;read‑only‑adgang til produktionsdatabaser\u0026rdquo;). Med Ansible blev konfigurationen af hver regel automatiseret og konsistens sikret på tværs af miljøer: udviklere fik kun adgang til deres tildelte servere, mens applikationsinstanser havde begrænsede rettigheder for at forhindre lateral bevægelse. Processen prioriterede klarhed frem for kompleksitet, med hver regel eksplicit knyttet til en rolle og et system.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResultat.\u003c/strong\u003e Implementeringen sikrede over 1.000 regler uden unødvendig kompleksitet og reducerede risikoen for uautoriseret adgang med 85 %. Automatiseringen strømlinede udrulningen og reducerede opsætningstiden med 60 % sammenlignet med manuelle metoder. Den dokumenterede ramme gjorde det muligt for teams hurtigt at revidere eller ændre regler og sikrede skalerbarhed, efterhånden som infrastrukturen voksede.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/da/portfolio/accelerated-postgresql-performance-by-10x-via-strategic-indexing-15/","url":"https://engineer.company/da/portfolio/accelerated-postgresql-performance-by-10x-via-strategic-indexing-15/","title":"Har accelereret PostgreSQL‑ydeevnen 10 gange via strategisk indeksering, partitionering og query‑optimering og forbedret databaseeffektiviteten for bruger-, tenant-, geospatiale og tidsserie‑eldata.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e PostgreSQL‑databasen betjente en mellemstor applikation, der håndterede brugerkonti, tenant‑oplysninger, geografiske data (lokationer, regioner) og daglige elforbrugsmetrikker. Mens systemet kørte under lav belastning, opstod der ydeevneproblemer, efterhånden som datamængderne voksede. Forespørgsler på geospatiale data og tidsserie‑ellogs blev langsomme, og mangel på optimeret indeksering, fragmenterede forespørgsler og upartitionerede tabeller forværrede problemet.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eOpgave.\u003c/strong\u003e Målet var at forbedre databasens ydeevne 10 gange uden at ændre den eksisterende arkitektur. Fokus var på at optimere forespørgselsudførelse, reducere latens og sikre skalerbarhed til fremtidig datavækst, herunder bedre svartider for geospatiale og tidsbaserede forespørgsler og bevaret dataintegritet.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eHandling.\u003c/strong\u003e Indeksering: Ofte forespurgte kolonner blev analyseret og målrettede indeks oprettet, herunder GiST‑indeks til geospatiale data og composite‑indeks til flerkolonnefiltre. Partitionering: Tidsbaseret range‑partitionering af eltabellen (pr. dag/måned) og hash‑partitionering af geografiske data blev implementeret. Query‑optimering: Komplekse forespørgsler blev omskrevet for at undgå full table scans, CTE\u0026rsquo;er og materialized views brugt, ineffektive joins identificeret med EXPLAIN ANALYZE og query caching og connection pooling konfigureret.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResultat.\u003c/strong\u003e Efter optimeringen forbedredes svartiderne 10 gange, med kritiske operationer (brugerautentifikation, geospatiale opslag) på millisekunder. Databasens ressourceforbrug faldt med 40 %, så systemet kunne håndtere øgede datamængder uden ydeevnetab. Brugerne oplevede mere flydende interaktioner, systemet blev mere skalerbart, og ændringerne reducerede behovet for hardwareopgraderinger og sparede omkostninger.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/da/portfolio/automated-gis-saas-application-deployment-data-processing-and-16/","url":"https://engineer.company/da/portfolio/automated-gis-saas-application-deployment-data-processing-and-16/","title":"Har automatiseret udrulning af GIS SaaS‑applikationer, databehandling og rapporteringssystem ved hjælp af GitHub Actions CI/CD, Python, Bash og SQL.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e Hos Utiligize var det at få GIS SaaS‑appen udrullet, behandle dens data og producere rapporterne alt sammen manuelle trin — og manuelle trin er både langsomme og stille farlige. Hver release åd engineering‑tid og bar chancen for en fejl, og det tilbagevendende data- og rapporteringsarbejde sad der og åd kapacitet uge efter uge.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eOpgave.\u003c/strong\u003e At automatisere hele vejen fra kode til produktion, plus det tilbagevendende databehandlings- og rapporteringsarbejde, var opgaven — målet var releases, der var hurtige, sikre og reproducerbare frem for et omhyggeligt manuelt ritual hver gang.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eHandling.\u003c/strong\u003e Hele vejen blev automatiseret. GitHub Actions‑pipelines overtog test‑build‑deploy‑cyklussen, så en release holdt op med at afhænge af, at nogen huskede trinene. Den tilbagevendende databehandling og rapporterne flyttede over i planlagte Python-, Bash- og SQL‑jobs, så de bare kørte i stedet for at være nogens pligt. Og konfigurationen og secrets blev standardiseret, så hvert miljø opførte sig ens — hvilket er det, der dræber \u0026ldquo;det virker på min maskine\u0026rdquo;-overraskelserne, for der holder op med at være en \u0026ldquo;min maskine\u0026rdquo;, der er anderledes end produktion.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResultat.\u003c/strong\u003e Udrulning, databehandling og rapportering blev alle automatiserede og pålidelige, det manuelle slid kom af teamets bord, og releasecyklussen blev kortere. Teamet kunne rette sin opmærksomhed mod produktet i stedet for driften, der var pakket omkring det.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/da/portfolio/automated-delivery-of-20-gis-data-pipelines-and-17/","url":"https://engineer.company/da/portfolio/automated-delivery-of-20-gis-data-pipelines-and-17/","title":"Har automatiseret levering af 20 GIS‑datapipelines og ETL‑processer for appdata og strømlinet infrastrukturautomatisering og rapportering.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e Platformen kørte på en masse GIS‑datapipelines og ETL‑processer for appdata, og de blev leveret og overvåget i hånden. Håndkørte pipelines skaber flaskehalse, de driver ud af konsistens, og værst af alt bærer de en konstant lav risiko for, at en stille fejler, og ingen bemærker det, før dataene allerede er forkerte længere nede.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eOpgave.\u003c/strong\u003e At automatisere leveringen af de pipelines og ETL‑processer — så dataene flød pålideligt og forudsigeligt uden nogen til at føre dem igennem — var opgaven.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eHandling.\u003c/strong\u003e Tyve GIS‑datapipelines og ETL‑processerne for appdata kom under automatiseret levering, fra ende til anden. Planlægningen, loggingen og fejlhåndteringen blev standardiseret, så hver pipeline opførte sig ens og, afgørende, man kunne se, når en ikke gjorde — en stille fejl er kun stille, hvis intet holder øje. Og de blev foldet ind i den eksisterende infrastrukturautomatisering og rapportering, så de var en del af ét sammenhængende system frem for en skuffe fuld af scripts, nogen skulle huske at køre.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResultat.\u003c/strong\u003e Alle tyve pipelines og deres ETL kørte automatisk og forudsigeligt, og hele billedet af infrastrukturautomatisering og rapportering blev pænere for det. Forretningen fik pålidelige, aktuelle data, uden at nogen skulle gå dem igennem i hånden — og uden den stille‑fejl‑risiko hængende over sig.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/da/portfolio/automated-100-critical-data-backups-using-barman-google-18/","url":"https://engineer.company/da/portfolio/automated-100-critical-data-backups-using-barman-google-18/","title":"Har automatiseret 100 kritiske databackups ved hjælp af Barman, Google Cloud, Bash og Python og sikret dataintegritet på tværs af databaser.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e De kritiske GIS‑data, applikationsinstanserne og databaserne var spredt over systemer med backups, der var inkonsistente og delvist manuelle. For et produkt, der lever på sine data, er det ikke en risiko, man kan lade ligge — og den dag, man faktisk har brug for en backup, er præcis den værste dag at finde ud af, at den var ufuldstændig.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eOpgave.\u003c/strong\u003e Opgaven var at garantere, at alle de kritiske data kunne gendannes, hvilket betød at automatisere omfattende, verificerede backups på tværs af hele estatet — verificerede som det ord, der betyder noget.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eHandling.\u003c/strong\u003e Backup‑regimet blev bygget fra ende til anden. Hundrede kritiske databackups blev automatiseret, med Barman på PostgreSQL‑siden og Google Cloud, der holdt offsite‑kopierne, og det hele blev orkestreret og valideret med Bash og Python — for en backup, man har taget, men aldrig tjekket, er ikke rigtig en backup, det er et håb. Så der var retention‑politikker til at holde dem aktuelle og integritetstjek til at bekræfte, at hver enkelt faktisk var god, ikke bare til stede.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResultat.\u003c/strong\u003e Backups kørte automatisk og kunne verificeres på tværs af hver database, hvilket gjorde datagenoprettelighed fra en antagelse til noget testet. En væsentlig driftsrisiko kom af forretningen og blev erstattet af en genopretningsvej, man faktisk kunne stole på — forskellen var, at denne var tjekket, ikke bare konfigureret.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/da/portfolio/deployed-and-maintained-20-docker-containerized-applications-troubleshooting-19/","url":"https://engineer.company/da/portfolio/deployed-and-maintained-20-docker-containerized-applications-troubleshooting-19/","title":"Har udrullet og vedligeholdt 20 Docker‑containeriserede applikationer, fejlfundet med Podman og Kubernetes og administreret R‑baserede apps på Google Cloud og AWS.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e Der var et voksende sæt containeriserede applikationer — herunder nogle R‑baserede analyseapps — der kørte på tværs af både Google Cloud og AWS. Spredt over to clouds og et par container‑runtimes skulle de udrulles konsistent og kunne diagnosticeres hurtigt, når noget gik galt, hvilket er sværere, end det lyder, når ikke to miljøer er helt ens.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eOpgave.\u003c/strong\u003e At udrulle og vedligeholde de workloads pålideligt, og at kunne diagnosticere problemer hurtigt på tværs af runtimes og clouds, var jobbet.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eHandling.\u003c/strong\u003e Det containeriserede estate blev administreret på tværs af begge clouds — tyve Docker‑applikationer udrullet og vedligeholdt med konsistent konfiguration og overvågning, så de ikke hver var deres eget snefnug. Når ting gik galt, gik fejlfindingen gennem Podman og orkestreringsdebugging gennem Kubernetes. De R‑baserede analyseapps fik dedikeret opmærksomhed i Google Cloud- og AWS‑produktionsmiljøerne, holdt stabile og reproducerbare, hvilket for analyse betyder noget — et resultat, man ikke kan reproducere, er ikke meget af et resultat.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResultat.\u003c/strong\u003e Det containeriserede estate kørte pålideligt på tværs af begge clouds, problemer blev diagnosticeret hurtigere, og udrulninger forblev stabile og reproducerbare. De applikationer, produktet lænede sig op ad, forblev pålidelige uanset hvilken cloud de nu tilfældigvis kørte i.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/da/portfolio/managed-30-ubuntu-linux-vps-instances-implementing-disaster-20/","url":"https://engineer.company/da/portfolio/managed-30-ubuntu-linux-vps-instances-implementing-disaster-20/","title":"Har administreret 30 Ubuntu Linux VPS‑instanser, implementeret disaster recovery‑strategier og sikret optimale netværkskonfigurationer.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e Utiligize kørte på en flåde af Ubuntu Linux VPS‑instanser, hvis opsætning var vokset organisk over tid — hvilket er en pæn måde at sige, den var akkumuleret frem for designet. Det efterlod huller: inkonsistente konfigurationer og genopretnings- og netværksarrangementer, der var mere historisk tilfældighed end plan.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eOpgave.\u003c/strong\u003e Opgaven var at få flåden under ordentlig styring, styrke disaster recovery‑siden og gøre netværkskonfigurationen konsistent og fornuftig på tværs af hver instans.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eHandling.\u003c/strong\u003e De tredive instanser kom under bevidst styring — behandlet som én sammenhængende flåde frem for tredive individuelle kæledyr. Rigtig disaster recovery gik ind: backups, og gendannelsesprocedurer, der faktisk blev testet, for en utestet gendannelse er bare en teori. Og netværkskonfigurationen blev standardiseret for sikkerhed og ydeevne, så hver instans fulgte den samme hærdede baseline i stedet for, hvad den nu tilfældigvis var endt med.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResultat.\u003c/strong\u003e Infrastrukturen blev robust og konsistent, med genopretningsveje, der var testet, og netværksdrift, man kunne stole på. Nedetidsrisikoen faldt, og forretningen endte med et solidt fundament at vokse på frem for en lappeløsning, den skulle blive ved med at passe.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/da/portfolio/prevented-security-breaches-by-leading-access-management-initiatives-21/","url":"https://engineer.company/da/portfolio/prevented-security-breaches-by-leading-access-management-initiatives-21/","title":"Har forhindret sikkerhedsbrud ved at lede initiativer inden for adgangsstyring med M365, 1Password, Red Hat SSO og OKTA SSO.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e Adgang til systemer og tjenester på tværs af Utiligize blev håndteret inkonsistent — rettigheder givet ad hoc, over tid, af forskellige folk. Det er et dobbelt problem: det åbner døren for adgang, ingen havde tænkt sig, og det gør revision næsten umulig, for ingen kan faktisk sige, hvem der kan nå hvad, eller hvorfor de kan.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eOpgave.\u003c/strong\u003e Målet var at lukke sikkerhedseksponeringen ved at centralisere og stramme adgangsstyringen på tværs af hele organisationen.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eHandling.\u003c/strong\u003e Eftersynet konsoliderede identiteterne og adgangen på tværs af M365, 1Password, Red Hat SSO og OKTA SSO, så der var et sammenhængende billede i stedet for spredte rettigheder pr. system. Least privilege blev håndhævet — personer og systemer havde præcis, hvad de havde brug for, og intet i overskud — og on- og offboarding standardiseret, så adgang blev givet og, lige så vigtigt, tilbagekaldt hurtigt og konsistent frem for at hænge ved, efter nogen var gået videre.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResultat.\u003c/strong\u003e Risikoen for uautoriseret adgang faldt markant, og adgang blev sporbar og konsistent — man kunne endelig svare på \u0026ldquo;hvem kan nå det her, og hvorfor.\u0026rdquo; Det mærkelige er, at det også gjorde hverdagen enklere for teamet: de rigtige døre åbnede let, og de forkerte forblev lukkede, hvilket er, hvad god adgangsstyring faktisk føles som.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/da/portfolio/mitigated-operational-risks-by-implementing-a-monitoring-dashboard-22/","url":"https://engineer.company/da/portfolio/mitigated-operational-risks-by-implementing-a-monitoring-dashboard-22/","title":"Har reduceret driftsrisici ved at implementere et monitoreringsdashboard med Grafana og Prometheus og forbedret systemets pålidelighed.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e Problemer hos Utiligize blev som regel først bemærket, efter de allerede havde ramt brugerne, fordi der ikke fandtes ét samlet overblik over, hvordan systemerne havde det. Uden det indblik var teamet permanent på bagfod — reagerede på ting, der allerede var gået galt, i stedet for at se dem komme.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eOpgave.\u003c/strong\u003e Målet var at skære driftsrisikoen ned ved at give teamet realtidsindblik i de systemer, de var afhængige af.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eHandling.\u003c/strong\u003e Observability‑laget blev bygget ud. Et monitoreringsdashboard på Grafana og Prometheus, de centrale tjenester instrumenteret, og — den del, der faktisk betyder noget — metrikker, der betød noget, frem for forfængelighedstal, der ser travle ud og fortæller en ingenting. Så alarmtærskler sat på dem, synliggjort der, hvor teamet faktisk ville se dem og kunne handle, mens der stadig var tid at handle i.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResultat.\u003c/strong\u003e Problemer begyndte at blive fanget og håndteret, før de eskalerede, og systemets pålidelighed blev bedre for det. Teamet skiftede fra reaktiv brandslukning til noget roligere og mere proaktivt — fangede problemer, mens de stadig var små nok til at være kedelige.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/da/portfolio/managed-and-troubleshooted-8-wireguard-vpn-and-ipsec-23/","url":"https://engineer.company/da/portfolio/managed-and-troubleshooted-8-wireguard-vpn-and-ipsec-23/","title":"Har administreret og fejlfundet 8 WireGuard VPN- og IPSEC VPN‑forbindelser og sikret sikker kommunikation på tværs af Google Cloud og Linux‑systemer.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e Sikker forbindelse mellem cloud\u0026rsquo;en og on‑premises‑Linux‑systemerne kørte over flere VPN‑tunneler, og de var skrøbelige og bøvlede at diagnosticere, når de faldt. En død tunnel kunne kappe kommunikationen mellem miljøer, og at fejlfinde en var langsomt og usikkert — man var aldrig helt sikker på, om man havde fundet den rigtige årsag.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eOpgave.\u003c/strong\u003e At administrere og fejlfinde de forbindelser, for at garantere sikker og uafbrudt kommunikation, var jobbet.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eHandling.\u003c/strong\u003e VPN‑estatet kom under kontrol — otte WireGuard- og IPSec‑tunneler på tværs af Google Cloud og Linux‑systemerne, administreret og fejlfundet som et sæt frem for otte separate mysterier. Deres konfiguration blev standardiseret, så de var konsistente og forståelige i stedet for hver at være sit eget særtilfælde, og deres tilstand blev overvåget, med de tilbagevendende routing- og key‑exchange‑problemer tacklet ved roden frem for lappet over med en genstart.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResultat.\u003c/strong\u003e Alle otte tunneler kørte sikkert og pålideligt, kommunikationen mellem miljøer forblev beskyttet, og de tilbagevendende forbindelsesproblemer, der plejede at afbryde arbejdet, holdt op med at ske. At rette rodårsagerne frem for at pleje symptomerne er det, der gjorde dem fra en tilbagevendende hovedpine til noget, der bare virkede.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/da/portfolio/led-the-software-development-of-a-gis-map-24/","url":"https://engineer.company/da/portfolio/led-the-software-development-of-a-gis-map-24/","title":"Har ledet softwareudviklingen af en GIS‑kortapplikation, øget omsætningen 10 gange og positioneret produktet som et primært dataaktiv.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e Kerneudfordringen var at bygge en platform, der kunne spore, overvåge og optimere vedvarende energiaktiver som solpaneler og vindmøller. Den oprindelige løsning manglede dog robuste geospatiale funktioner, hvilket gjorde det svært for kunder at visualisere aktivlokationer, analysere spatiale data eller udlede handlingsorienterede indsigter. Ledelsen prioriterede derfor udviklingen af en GIS‑kortapplikation for at øge platformens værdi.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eOpgave.\u003c/strong\u003e Opgaven var at lede udviklingen af GIS‑applikationen, en kritisk komponent til at differentiere produktet på det konkurrenceprægede marked for grøn energi. Rollen strakte sig ud over softwareudvikling — som teknisk leder, DevOps‑ingeniør, dataingeniør og SRE. Målet var at skabe et skalerbart, intuitivt GIS‑værktøj, der integrerede problemfrit med SaaS‑platformen, og som kunne udvikle sig i takt med virksomheden.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eHandling.\u003c/strong\u003e Det begyndte med at samarbejde med interessenter om at definere applikationens kernefunktioner med fokus på integration med den eksisterende SaaS‑platform og realtidsvisualisering. På grund af det lille team blev en modulær arkitektur designet med open source‑GIS‑biblioteker for at holde systemet let og skalerbart. CI/CD‑pipelines, automatiseret infrastrukturprovisionering og overvågning blev også implementeret. Efterhånden som teamet voksede, blev nye ingeniører mentoreret, tværfagligt samarbejde faciliteret og brugerfeedback prioriteret for at forfine applikationen iterativt.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResultat.\u003c/strong\u003e GIS‑applikationen blev en hjørnesten i SaaS‑platformen og drev en 10‑dobbelt stigning i omsætningen gennem mersalg, datalicensering og nye kunder. Dens evne til at visualisere grønne energiaktiver i realtid forbedrede kundernes driftseffektivitet, og den løbende forfining positionerede den som et primært dataaktiv. Projektets succes styrkede virksomhedens omdømme i sektoren for vedvarende energi og demonstrerede værdien af en tværfaglig tilgang i et hurtigt voksende startup‑miljø.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/da/portfolio/directed-full-stack-gis-map-development-overseeing-postgresql-25/","url":"https://engineer.company/da/portfolio/directed-full-stack-gis-map-development-overseeing-postgresql-25/","title":"Har styret full‑stack‑udvikling af GIS‑kort med ansvar for PostgreSQL, Mapbox, ReactJS og NodeJS for at levere en integreret løsning.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e På det her tidspunkt var GIS‑kortet holdt op med at være en funktion og var blevet grunden til, at kunderne overhovedet loggede ind. Problemet var, at det var vokset op i stumper. De spatiale data lå i PostgreSQL, selve kortet blev tegnet med Mapbox, og applikationen omkring det var ReactJS i frontenden med NodeJS bagved. Hver del virkede for sig. De var bare ikke bygget til at passe sammen, og sømmene begyndte at vise sig.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eOpgave.\u003c/strong\u003e Rollen dækkede full‑stack‑udviklingen af kortet og den tekniske retning, der fulgte med: datamodellen, renderingen, API\u0026rsquo;et og React‑frontenden. Målet var at gøre fire ting, der tilfældigvis delte et repository, til ét produkt, der var værd at stå inde for.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eHandling.\u003c/strong\u003e Arkitekturen blev fastlagt først, og så blev arbejdet tæt på koden i stedet for at styre på afstand. På datasiden blev den spatiale model i PostgreSQL holdt ryddelig, så forespørgslerne ikke sneglede sig af sted, efterhånden som datasættene voksede. Mapbox stod for tegningen; opgaven var at fodre den med de rigtige data på de rigtige zoomniveauer i stedet for det hele på én gang. På applikationssiden blev ReactJS- og NodeJS‑arbejdet reviewet, teamet skubbet mod fælles konventioner, og ansvar flyttet tilbage til det lag, det hørte til i, når ét begyndte at lække ind i det næste. En god del af det var uglamourøst arbejde: at fange de små inkonsistenser, før de størknede til arkitektur.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResultat.\u003c/strong\u003e Det, der kom ud, var én integreret kortapplikation, hvor data, rendering og grænseflade endelig trak samme vej. Den blev en central del af platformen og noget, teamet kunne blive ved med at bygge videre på, uden at den knækkede sammen, hver gang et lag blev tilføjet.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/da/portfolio/saved-4-000-hours-by-mentoring-and-growing-26/","url":"https://engineer.company/da/portfolio/saved-4-000-hours-by-mentoring-and-growing-26/","title":"Har sparet 4.000 timer ved at mentorere og udvide et team fra 2 til 18 medlemmer, optimere workflows og fremme tværfagligt samarbejde.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e Et team på to kunne ikke følge med længere. Produktet trak mere arbejde ind, end et par mennesker kunne levere, og måden, arbejdet foregik på — viden i hovederne, ingen rigtige konventioner — ville ikke overleve at blive skaleret op. At kaste flere folk efter et så løst team gør som regel bare kaosset større.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eOpgave.\u003c/strong\u003e Opgaven var at udvide teamet og samtidig bygge den struktur, der ville lade en større gruppe bevæge sig hurtigere i stedet for langsommere. At mentorere de nye var den ene halvdel. At rette arbejdsgangene, så ingen gik i stå og ventede på en anden, var den anden.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eHandling.\u003c/strong\u003e Teamet voksede fra 2 til 18 over tid, med ansættelsen og mentoreringen behandlet som det samme job: alle, der kom til, skulle kunne arbejde uden opsyn. Fælles standarder betød, at kode og proces så ens ud uanset hvem der skrev dem, og der blev lagt reelt arbejde i overleveringerne mellem specialer, for det er dér, teams stille og roligt taber deres dage. Når noget blev ved med at spænde ben, gik rettelsen til processen i stedet for symptomet.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResultat.\u003c/strong\u003e Det større, bedre mentorerede team, der kørte på arbejdsgange, der faktisk var designet, sparede i omegnen af 4.000 timer. Men tallet er ikke rigtig pointen. Det, der blev bygget, var varig engineering‑kapacitet — en gruppe, der kunne bære arbejdet, uanset om nogen enkelt person var i rummet eller ej.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/da/portfolio/optimized-forecasting-and-investment-strategies-for-11-electricity-27/","url":"https://engineer.company/da/portfolio/optimized-forecasting-and-investment-strategies-for-11-electricity-27/","title":"Har optimeret prognose- og investeringsstrategier for 11 eldistributionsoperatører og øget driftseffektiviteten gennem datadrevne GIS‑løsninger.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e Eldistributionsoperatører står og falder på beslutninger om, hvor de skal forstærke nettet, og hvor de skal placere deres penge, og elleve af dem traf de beslutninger uden meget geospatial analyse under sig. De havde driftsdataene. Det, de ikke havde, var en måde at se dem på kortet, dér hvor mønstrene faktisk lever.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eOpgave.\u003c/strong\u003e Opgaven var at skærpe deres prognoser og investeringsstrategier med GIS — at gøre tabeller af aflæsninger til noget, der viste dem, hvor kapaciteten blev knap, hvor risikoen byggede sig op, og hvor den næste krone var bedst givet ud.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eHandling.\u003c/strong\u003e Deres driftsdata blev bragt sammen med geospatial modellering, så de to forstærkede hinanden. I stedet for at lave prognoser i det abstrakte kunne nettet ses rumligt og stilles konkrete spørgsmål: hvilke strækninger var på vej mod deres grænser, hvilke områder retfærdiggjorde investering først. For elleve operatører betød det at tilpasse analysen til, hvordan hver af dem faktisk drev deres net, ikke at række alle den samme skabelon og håbe, den passede.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResultat.\u003c/strong\u003e Operatørerne gik derfra med prognoser, de kunne stole på, og investeringsbeslutninger, der var målrettede frem for håbefulde. At forankre planlægningen i det, kortet viste, gjorde det hele mere effektivt — penge og opmærksomhed gik derhen, hvor dataene pegede, i stedet for derhen, hvor vanen gjorde.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/da/portfolio/presented-200-ui-ux-improvements-for-the-gis-28/","url":"https://engineer.company/da/portfolio/presented-200-ui-ux-improvements-for-the-gis-28/","title":"Har præsenteret 200 UI/UX‑forbedringer til GIS‑kortapplikationen og øget omsætningen 10 gange gennem forbedrede softwarefunktioner.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e Kortgrænsefladen var blevet kraftfuld og undervejs kompliceret. Der var steder, hvor man kunne mærke kunderne ikke få den værdi, der sad lige foran dem — god funktionalitet fanget bag klodsede interaktioner. Det gab mellem, hvad produktet kunne, og hvad folk fandt let at gøre, kostede os stille og roligt.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eOpgave.\u003c/strong\u003e Opgaven var at finde de gab og skubbe rettelserne igennem: det brugervenlighedsarbejde, der ville gøre produktet lettere at få værdi ud af og — ikke tilfældigt — mere værd kommercielt.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eHandling.\u003c/strong\u003e I stedet for at gætte på, hvad der var galt, gik arbejdet i feedbacken og brugsdataene, og ud af det kom en backlog på 200 konkrete UI/UX‑forbedringer. De blev ikke behandlet som ens — rangeret efter effekt, med dem, der betød noget, argumenteret for og ført gennem teamet for at blive sendt ud som rigtige funktioner i stedet for en ønskeliste, der lå og blev forældet i et dokument.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResultat.\u003c/strong\u003e Grænsefladen blev mærkbart bedre at bruge, og produktets værdi fulgte efter: arbejdet bidrog til en tidobling af omsætningen. Det er et eksempel, der er værd at vende tilbage til, fordi det gør pointen rent — omhyggeligt UX‑arbejde er ikke kosmetik, det dukker op på fakturaen.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/da/portfolio/designed-and-managed-5-000-hours-of-map-29/","url":"https://engineer.company/da/portfolio/designed-and-managed-5-000-hours-of-map-29/","title":"Har designet og styret 5.000 timers kortudvikling ved hjælp af agile metoder som Scrum og Jira for effektiv projektledelse.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e Kortet blev ikke bygget i en sprint. Det var tusindvis af timers arbejde spredt over en masse mennesker og en masse måneder, og den slags indsats skrider, hvis ingen holder linjen på scope og tidsplan. Overladt til sig selv bliver den stille og roligt forsinket.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eOpgave.\u003c/strong\u003e Ansvaret var at designe og køre udviklingsindsatsen, så den blev leveret med vilje frem for ved held — at holde prioriteterne ærlige og fremdriften synlig for enhver, der ville kigge.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eHandling.\u003c/strong\u003e Det kørte på agile: ordentlig Scrum, med ceremonierne faktisk brugt frem for opført, og arbejdet sporet i Jira, så folk kunne se, hvor tingene stod, uden at skulle spørge. Et sted omkring 5.000 timers kortudvikling gik gennem den proces. Vægten lå mindre på ceremoni for dens egen skyld og mere på at holde prioriteterne rettet mod det, der betød noget, og fange skred tidligt, mens det stadig var billigt at rette.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResultat.\u003c/strong\u003e De 5.000 timer landede på en kontrolleret, synlig måde i stedet for at forsvinde ind i en sort boks. Projektledelsen gjorde det, den skal — og det, der mest går ubemærket hen, når den virker: den holdt arbejdet afstemt med målene og nogenlunde på tidsplanen, uden heltemod til sidst.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/da/portfolio/wrote-50-000-words-of-comprehensive-software-documentation-30/","url":"https://engineer.company/da/portfolio/wrote-50-000-words-of-comprehensive-software-documentation-30/","title":"Har skrevet 50.000 ord omfattende softwaredokumentation med Markdown i GitHub, Craft og Confluence og derved sikret fastholdelse af viden og gennemsigtighed i processen.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e Det meste af det, der betød noget om produktet, og om hvordan teamet arbejdede, lå i folks hoveder. Det går fint lige indtil nogen ny kommer til, eller nogen forlader firmaet — og så sneglede onboardingen sig af sted, og en klump institutionel hukommelse var én opsigelse fra at være væk for altid.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eOpgave.\u003c/strong\u003e Målet var at få den viden ud af hovederne og ind i dokumentation, folk faktisk ville beholde og bruge: klar nok til at blive læst, struktureret nok til at blive vedligeholdt frem for droppet efter en måned.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eHandling.\u003c/strong\u003e En stor del af den blev skrevet i hånden, omkring 50.000 ord til sidst, i Markdown på tværs af GitHub, Craft og Confluence alt efter hvor hvert stykke hørte til. Den dækkede arkitekturen, processerne og det praktiske how‑to‑materiale — de spørgsmål, folk blev ved med at stille. Den blev holdt versionsstyret og, mindst lige så vigtigt, mulig at finde, for dokumentation, ingen kan lokalisere, kan lige så godt ikke eksistere.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResultat.\u003c/strong\u003e Videnen holdt op med at være skrøbelig. Nye folk kom hurtigere op i tempo, processen blev noget, man kunne pege på i stedet for at rekonstruere efter hukommelsen, og det hele blev reviderbart: man kunne se hvordan og hvorfor arbejdet blev gjort frem for at tage det på tro.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/da/portfolio/gathered-and-analyzed-business-requirements-to-translate-into-31/","url":"https://engineer.company/da/portfolio/gathered-and-analyzed-business-requirements-to-translate-into-31/","title":"Har indsamlet og analyseret forretningskrav og omsat dem til konkrete funktioner og user stories i overensstemmelse med data governance‑standarder.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e Krav plejede at ankomme som samtaler — nogen ville have noget, sådan cirka, og det faldt tilbage på udviklerne at gætte på kanterne. At gætte betyder omarbejde, og omarbejde er omtrent den dyreste måde, der findes, at bygge noget på.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eOpgave.\u003c/strong\u003e Rollen sad mellem forretningen og engineeringen og oversatte den ene til den anden: at gøre løse behov til arbejde, en udvikler kunne tage fat på uden at gætte, og at holde det i tråd med data governance‑standarderne undervejs.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eHandling.\u003c/strong\u003e Kravene blev arbejdet ud med interessenterne direkte, med de akavede spørgsmål stillet tidligt i stedet for opdaget sent, og skrevet op som funktioner og user stories, der faktisk sagde, hvad \u0026ldquo;færdig\u0026rdquo; betød. Hver enkelt blev holdt op mod governance‑reglerne, for en funktion, der er nyttig, men håndterer data forkert, er ikke rigtig færdig. Hele formålet var, at nogen kunne læse en story og bygge det rigtige første gang.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResultat.\u003c/strong\u003e Udviklingen kørte ud fra klare, aftalte funktioner i stedet for halvt forståede ønsker. Tvetydigheden faldt, og omarbejdet faldt med den, og leveringen forblev rettet mod de faktiske forretningsmål — inden for data governance‑linjerne frem for pyntet til at passe bagefter.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/da/portfolio/managed-the-execution-of-30-successful-gis-projects-32/","url":"https://engineer.company/da/portfolio/managed-the-execution-of-30-successful-gis-projects-32/","title":"Har styret gennemførelsen af 30 succesfulde GIS‑projekter og udvist lederskab i leveringen af innovative løsninger på tværs af feltet.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e Mappitall tjente sine penge på at levere GIS‑projekter, og der kørte mange af dem på én gang. Virksomhedens vækst red på at få dem ud ad døren pålideligt — ikke ét flagskibsprojekt gjort strålende, men en stabil strøm af dem, der landede til tiden og hang sammen, hvilket kun sker, når koordineringen på tværs af teamet faktisk fungerer.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eOpgave.\u003c/strong\u003e Ansvaret var at få den portefølje leveret — at holde scope, folk og tidsplaner på linje på tværs af det hele og give teamet den retning, der skulle til for at levere.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eHandling.\u003c/strong\u003e Gennem de år kørte leveringen af tredive GIS‑projekter gennem den her rolle. I praksis betød det at holde scope i ro, når det ville krybe, at pege de rigtige folk mod det rigtige arbejde og at være tæt nok på hvert projekt til at fange problemer, mens de stadig var små. Når noget var ved at skride, bedre at vide det tidligt og rokere om end finde ud af det ved deadline. En stor del af jobbet var bare at holde tallerknerne i luften og kundens forventninger ærlige om, hvad der kom hvornår.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResultat.\u003c/strong\u003e Alle tredive kom i mål. Den konsistens betød mere, end noget enkelt projekt ville have gjort — en kunde, der har set dig levere tredive gange, bekymrer sig ikke om den enogtredivte, og det omdømme er en god del af, hvorfor virksomheden blev ved med at vokse.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/da/portfolio/led-company-growth-from-4-to-14-employees-33/","url":"https://engineer.company/da/portfolio/led-company-growth-from-4-to-14-employees-33/","title":"Har ledet virksomhedens vækst fra 4 til 14 medarbejdere ved at anvende agile metoder og effektiv projektledelse.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e Mappitall var klar til at vokse, og der er en bestemt fare i det øjeblik: man tilføjer folk hurtigere, end man tilføjer proces, og både kvaliteten og den fælles fornemmelse af, hvordan tingene gøres, begynder at flosse. Fire personer, der alle ved, hvad alle andre laver, er noget helt andet end fjorten, der ikke gør.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eOpgave.\u003c/strong\u003e At lede den vækst var jobbet — at få folk ind og samtidig holde leveringen disciplineret og teamet trækkende i samme retning.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eHandling.\u003c/strong\u003e Virksomheden gik fra fire personer til fjorten. Det var ansættelse og onboarding gjort bevidst frem for i panik, men den større brik var at få de arbejdsmåder på plads, der lod et team af den størrelse ikke snuble over sig selv — agile praksisser, rigtig projektledelse, de vaner, der holder alles arbejde synligt for alle andre. Den tiende og fjortende ansættelse skulle træde ind i noget, der allerede havde en form, ikke gætte sig til, hvordan tingene blev gjort.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResultat.\u003c/strong\u003e Teamet nåede fjorten, uden at kvaliteten faldt, eller det splintrede i folk, der ikke vidste, hvad de andre var i gang med. Det agile er det, der holdt en større gruppe produktiv — processen voksede med antallet af hoveder i stedet for at halte bagefter.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/da/portfolio/improved-team-communication-and-collaboration-by-implementing-slack-34/","url":"https://engineer.company/da/portfolio/improved-team-communication-and-collaboration-by-implementing-slack-34/","title":"Har forbedret teamets kommunikation og samarbejde ved at implementere Slack, Mattermost, 1Password og Jira og sparet 8.000 arbejdstimer.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e Efterhånden som teamet blev større, havde kommunikationen og værktøjerne ikke fulgt med, og det kunne mærkes. Ting blev sagt ét sted og overset af dem, der havde brug for dem, arbejde blev lavet dobbelt, fordi ingen kunne se, hvad en anden allerede havde gjort, og at koordinere noget som helst tog længere tid end selve arbejdet. Den slags friktion er usynlig fra dag til dag, men den løber op i en masse tabt tid.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eOpgave.\u003c/strong\u003e Målet var at rette op på, hvordan teamet kommunikerede og arbejdede sammen, og kradse den tid tilbage, der stille og roligt blev blødt til al den friktion.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eHandling.\u003c/strong\u003e Værktøjerne blev indført og standardiseret, og — det er den del, der faktisk betyder noget — praksis for at bruge dem blev sat, så de ikke bare blev endnu et sted at tjekke. Slack og Mattermost til kommunikation, 1Password, så delte secrets ikke blev sendt rundt på måder, ingen kunne holde styr på, Jira, så arbejdet blev tracket ét sted i stedet for at leve i folks hoveder og indbakker. Værktøjerne var den nemme del; at få alle til faktisk at bruge dem på samme måde var det egentlige arbejde.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResultat.\u003c/strong\u003e Kommunikation og samarbejde blev mærkbart bedre, og det strømlinede opsæt sparede noget i størrelsesordenen 8.000 arbejdstimer — tid, der havde gået til at jage information og lave arbejde om, som nu gik til faktisk levering.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/da/portfolio/led-the-development-deployment-and-support-of-over-35/","url":"https://engineer.company/da/portfolio/led-the-development-deployment-and-support-of-over-35/","title":"Har ledet udvikling, idriftsættelse og support af over 30 GIS‑projekter og udvist ekspertise i PostgreSQL, Bash, Python, JavaScript, GDAL, ArcGIS, PostGIS og Mapbox.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e Virksomhedens hele output var made‑to‑measure GIS — skræddersyet kortlægning og geodata‑systemer bygget til en kundes konkrete problem og så holdt kørende, når de var live. At bygge tingen er kun halvdelen; et geospatialt projekt, der ryger ud og så vælter i produktion, er ikke rigtig blevet leveret.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eOpgave.\u003c/strong\u003e De projekter kørte fra ende til anden gennem den her rolle — udviklingen, udrulningen og supporten, når de først var live — med den tekniske retning på tværs af en ret bred stak.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eHandling.\u003c/strong\u003e Leveringen kørte på mere end tredive GIS‑projekter, hands‑on på tværs af stakken hele vejen. PostgreSQL med PostGIS under til geodataene, GDAL/OGR til at flytte dem mellem formater — shapefiles, GeoJSON, GeoTIFF, KML, vector tiles — og QGIS og JOSM til selve dataarbejdet. Foran på det webkort bygget på Mapbox GL og Leaflet, nogle gange mod ArcGIS- eller HERE‑API\u0026rsquo;erne, med app‑laget i JavaScript, Python, PHP og SQL. Arbejdet spændte fra 2D- og 3D‑digital kortlægning over LiDAR‑behandling, georektifikation og vektorisering til indendørs kortlægning og navigation. Og ansvaret rakte forbi det punkt, tingen var sendt af sted — udrulningen og den løbende support i produktion var også en del af det, så problemer blev ikke givet videre; beslutningerne skulle leves med.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResultat.\u003c/strong\u003e Tredive‑plus projekter bygget, udrullet og supporteret på tværs af hele det spænd. At stå på krogen for hele livscyklussen frem for bare bygget er det, der holdt kvaliteten ærlig — man designer anderledes, når man ved, det er en selv, der får opkaldet, hvis det går i stykker.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/da/portfolio/contributed-to-user-interface-design-processes-ensuring-intuitive-36/","url":"https://engineer.company/da/portfolio/contributed-to-user-interface-design-processes-ensuring-intuitive-36/","title":"Har bidraget til designprocesser for brugergrænseflader og sikret intuitive, visuelt tiltalende og brugervenlige projektgrænseflader.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e Grænsefladerne på tværs af projekterne var ujævne. Nogle var fine, nogle var tydeligvis bygget af ingeniører, der tænkte på datamodellen frem for den person, der skulle bruge dem, og designbeslutningerne blev ikke altid truffet med slutbrugeren i rummet. På et webkort‑produkt især er kortet den nemme del — det er kontrollerne, filtreringen og flowet rundt om det, hvor folk farer vild.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eOpgave.\u003c/strong\u003e At blande sig i UI‑designprocessen var en del af rollen — for at hjælpe med at gøre grænsefladerne til noget, folk faktisk fandt intuitivt og behageligt at bruge, ikke bare funktionelt.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eHandling.\u003c/strong\u003e Rollen var ikke designerens, men den sad med i designprocessen og bragte et engineering‑perspektiv ind — pressede på layout, på flowet gennem en opgave, på om en skærm faktisk var klar eller bare var velkendt for dem, der havde bygget den. Det her var React-, Angular- og Vue‑frontends oven på Mapbox- og Leaflet‑kort, og en stor del af brugervenligheden lå i detaljerne: hvordan man filtrerede et datasæt, hvordan man skiftede mellem etager på et indendørskort, om tingen fortalte dig, hvad den lavede. Mest af alt betød det at stille de dumme brugerspørgsmål tidligt, mens de stadig var billige at rette, i stedet for efter release, når forvirringen kom tilbage som supportsager.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResultat.\u003c/strong\u003e Grænsefladerne blev mere intuitive og mere forfinede, hvilket slutbrugerne mærkede direkte, og det løftede den samlede kvalitet af det, der blev sendt ud. At få brugervenlighedsspørgsmålene stillet under design frem for efter release er det meste af, hvad der gjorde forskellen.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/da/portfolio/guided-the-execution-of-numerous-company-projects-offering-37/","url":"https://engineer.company/da/portfolio/guided-the-execution-of-numerous-company-projects-offering-37/","title":"Har vejledt gennemførelsen af talrige virksomhedsprojekter og ydet ekspertsupport i softwareudviklingsfaserne.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e Der kørte mange projekter på samme tid, hvert midt i sin udviklingsfase, og de havde alle brug for stabil teknisk vejledning for at blive på sporet. Ladt alene driver projekter — en forkert tilgang taget tidligt bliver dyr, når først nogen bemærker det.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eOpgave.\u003c/strong\u003e At vejlede den gennemførelse var jobbet — at være den tekniske support, teamene kunne læne sig op ad gennem udviklingsfaserne.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eHandling.\u003c/strong\u003e Arbejdet holdt sig hands‑on på tværs af mange af virksomhedens projekter på én gang. Det betød at fjerne blokeringer, når folk sad fast, at kigge hårdt på en tilgang, før for meget blev bygget oven på den, og generelt at være tæt nok på til at fange et projekt på vej i den forkerte retning, mens det stadig var en kurskorrektion og ikke en genbygning. Idéen var at være tilgængelig frem for en port — at holde tingene i bevægelse, ikke at få alt til at vente på én person.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResultat.\u003c/strong\u003e Projekterne bevægede sig mere gnidningsfrit gennem deres vanskelige udviklingsfaser med en erfaren at læne sig op ad på de rigtige tidspunkter, og det stabiliserede leveringen tværs igennem virksomhedens portefølje.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/da/portfolio/overhauled-internal-processes-saving-8-000-hours-by-38/","url":"https://engineer.company/da/portfolio/overhauled-internal-processes-saving-8-000-hours-by-38/","title":"Har gennemgribende fornyet interne processer og sparet 8.000 timer ved at forbedre softwarearkitektur, systemer og planlægningseffektivitet.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e Måden, tingene blev gjort internt på, havde samlet den sædvanlige rust — softwarearkitektur, der var vokset ved aflejring frem for design, systemer, der virkede, men ikke effektivt, planlægning, der lod folk enten vente eller være pressede. Intet af det brændte, hvilket er præcis derfor, det var blevet ladt i fred, men det kostede stille og roligt en masse tid.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eOpgave.\u003c/strong\u003e Målet var at forny de processer gennemgribende — at gå ud og finde spildet og tage det ud frem for at blive ved med at betale for det.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eHandling.\u003c/strong\u003e De interne processer blev omarbejdet på tre fronter: softwarearkitekturen, så den var noget, man kunne ræsonnere om og bygge på i stedet for at arbejde uden om; systemerne, strømlinet, så det rutineprægede arbejde holdt op med at tage længere tid, end det burde; og planlægningen, så kapaciteten faktisk blev matchet med arbejdet. Og ændringerne blev gjort til at sidde fast — forankret i, hvordan teamet opererede, frem for efterladt som et notat, alle nikkede til og glemte — for procesforbedringer, der ikke gøres permanente, forfalder bare tilbage til den gamle måde.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResultat.\u003c/strong\u003e Fornyelsen sparede omkring 8.000 timer ved at gøre arkitekturen, systemerne og planlægningen mærkbart mere effektive. Det er kapacitet, der gik direkte tilbage i arbejde med højere værdi i stedet for i overhead, ingen havde tænkt på at stille spørgsmål ved.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/da/portfolio/administered-network-infrastructure-for-over-1-000-servers-39/","url":"https://engineer.company/da/portfolio/administered-network-infrastructure-for-over-1-000-servers-39/","title":"Har administreret netværksinfrastruktur for over 1.000 servere og sikret optimal systemudrulning, sikkerhed og fejlfinding.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e Virksomhedens drift sad oven på et stort serverestate — over tusind af dem — og et estate af den størrelse holder sig ikke pålideligt af sig selv. Udrulning, sikkerhed og den stadige strøm af ting, der går galt, kræver alle en, der kører dem med faktisk disciplin, ellers bliver det hele ustabilt, og ingen er helt sikre på hvorfor.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eOpgave.\u003c/strong\u003e At administrere den netværksinfrastruktur var jobbet — at holde den sikker, holde den pålidelig, holde den konsistent i en skala, hvor inkonsistens er det, der slår en ihjel.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eHandling.\u003c/strong\u003e Netværksinfrastrukturen kørte på tværs af mere end tusind servere. Hvordan systemer blev udrullet blev standardiseret, så en server kom op på den samme forudsigelige måde i stedet for hver at være en lille smule specialbygget; sikkerheden blev hærdet frem for at stole på, at ingen ville komme og lede; og fejlfindingen blev håndteret, når noget først gik i stykker. I den skala er standardiseringen det, der redder en — tusind snefnug er uadministrerbart, tusind af den samme ting er bare arbejde.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResultat.\u003c/strong\u003e Estatet kørte med pålidelig udrulning, solid sikkerhed og problemer, der blev håndteret prompte i stedet for at ulme. Det er den slags infrastrukturarbejde, der er usynligt, når det går godt, hvilket er pointen — det var den stabile rygrad, alt andet i virksomheden kørte på.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/da/portfolio/established-a-technical-support-department-servicing-over-10-40/","url":"https://engineer.company/da/portfolio/established-a-technical-support-department-servicing-over-10-40/","title":"Har etableret en teknisk supportafdeling, der har betjent over 10.000 kunder med IT‑support og fejlfindingsløsninger.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e Kundebasen voksede og havde brug for pålidelig teknisk support, og der var bare ikke en dedikeret funktion til at give dem den i nogen egentlig skala. Support skete ad hoc, hvilket virker for en håndfuld kunder og stille og roligt falder fra hinanden, efterhånden som tallene klatrer.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eOpgave.\u003c/strong\u003e At rejse en egentlig teknisk supportkapacitet — en, der kunne betjene en stor og stadig voksende kundebase — var jobbet.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eHandling.\u003c/strong\u003e En teknisk supportafdeling blev bygget op fra ingenting. Det betød at beslutte, hvordan den faktisk skulle fungere, før der blev ansat ind i den — processen for, hvordan en henvendelse kom ind og blev løst, værktøjerne til at håndtere mængden, standarden for, hvordan god support så ud — og så bygge kapaciteten til at levere IT‑support og fejlfinding til mange kunder på én gang. At starte fra bunden var ærligt talt fordelen; den kunne designes til den skala, virksomheden var på vej mod, i stedet for at lappe på noget, der var vokset op ved et tilfælde.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResultat.\u003c/strong\u003e Afdelingen endte med at betjene over ti tusind kunder med pålidelig support og fejlfinding. Support gik fra en ting, der blev gjort reaktivt, til en ægte styrke for virksomheden — noget, der skalerede med kundebasen i stedet for at bukke under for den.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/da/portfolio/automated-ssl-tls-certificate-creation-for-100-docker-41/","url":"https://engineer.company/da/portfolio/automated-ssl-tls-certificate-creation-for-100-docker-41/","title":"Har automatiseret oprettelse af SSL/TLS‑certifikater for 100 Docker‑applikationer og sikret sikre forbindelser på tværs af Ubuntu Linux‑hosts.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e Hundrede Docker‑applikationer havde alle brug for SSL/TLS‑certifikater, og certifikater er den slags, der er fint lige indtil de ikke er. At udstede og forny hundrede af dem i hånden er langsomt, det er kedeligt, og det er præcis den slags manuelle job, hvor én glemt fornyelse tager en app ned med en udløbsfejl på det værst tænkelige tidspunkt.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eOpgave.\u003c/strong\u003e Målet var oprettelse og fornyelse af certifikater automatiseret — hver app med gyldig, betroet kryptering, og ingen der skulle huske at gøre noget.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eHandling.\u003c/strong\u003e Et ACME‑baseret workflow håndterede hele livscyklussen for de hundrede Docker‑applikationer — oprettede certifikaterne og fornyede dem, før de udløb — og udrullede dem automatisk på tværs af Ubuntu Linux‑hostene, der kørte en blanding af Apache og Nginx. Hele målet var at tage mennesket ud af det, for mennesket er den del, der glemmer.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResultat.\u003c/strong\u003e Alle hundrede applikationer holdt gyldige certifikater og sikre forbindelser af sig selv. Det manuelle certifikatarbejde forsvandt bare, og med det hele den kategori af nedbrud, hvor noget går i stykker, ikke fordi det fejlede, men fordi et certifikat stille og roligt udløb, og ingen bemærkede det.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/da/portfolio/streamlined-ci-cd-processes-saving-4-000-hours-42/","url":"https://engineer.company/da/portfolio/streamlined-ci-cd-processes-saving-4-000-hours-42/","title":"Har strømlinet CI/CD‑processer og sparet 4.000 timer ved at indføre automatisering i softwareudviklingspipelines.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e At få software ud ad døren afhang af manuelle, inkonsistente trin — nogen der huskede rækkefølgen og gjorde det en anelse forskelligt hver gang — og det bremsede releases og åd engineering‑timer, der skulle være gået til at bygge ting.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eOpgave.\u003c/strong\u003e Målet var at strømline CI/CD‑processen og få automatisering ind i pipelines, så releases holdt op med at være et manuelt ritual.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eHandling.\u003c/strong\u003e Automatiserede build-, test- og udrulningspipelines blev sat op, så vejen fra en ændring til, at den kørte i produktion, var standardiseret i stedet for improviseret. De gentagne manuelle trin — dem, der var langsomme og, værre, blev gjort forskelligt afhængigt af, hvem der gjorde dem — kom ud. Når først pipelinen gør det på samme måde hver gang, holder en hel klasse af \u0026ldquo;det virkede på min maskine\u0026rdquo; og halvt huskede udrulningstrin bare op med at ske.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResultat.\u003c/strong\u003e Automatiseringen gav omkring 4.000 timer tilbage og gjorde releases både hurtigere og mere pålidelige. Teamet kunne udgive uden at spænde ben for det — tilliden kom fra, at processen var konsistent, ikke fra at alle var forsigtige.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/da/portfolio/streamlined-data-analysis-and-software-development-processes-saving-43/","url":"https://engineer.company/da/portfolio/streamlined-data-analysis-and-software-development-processes-saving-43/","title":"Har strømlinet processer for dataanalyse og softwareudvikling og sparet 4.000 timer ved at indføre CI/CD‑praksis med GitHub, GitLab, Bash og Python.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e Både dataanalysearbejdet og softwareudviklingen blev holdt tilbage af det samme: manuelle processer. Arbejde bevægede sig fra udvikling til levering på en langsom, inkonsistent måde, og analysesiden havde sin egen bunke gentagne trin, som nogen lavede i hånden hver gang.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eOpgave.\u003c/strong\u003e Målet var at strømline begge dele ved at bringe moderne automatisering og CI/CD‑praksis til workflows, der ikke havde haft dem.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eHandling.\u003c/strong\u003e CI/CD‑praksis blev indført, bygget på GitHub og GitLab, med Bash og Python, der lavede automatiseringsarbejdet nedenunder. De gentagne trin på tværs af både dataanalyse- og udviklingsworkflows blev automatiseret, og hvordan arbejdet bevægede sig fra udvikling og hele vejen til levering blev standardiseret, så det var det samme hver gang frem for genopfundet pr. projekt. At bringe analysesiden ind i den samme disciplinerede pipeline som udviklingsarbejdet var en stor del af det — den var blevet behandlet som en separat, mere manuel verden.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResultat.\u003c/strong\u003e De strømlinede processer sparede omkring 4.000 timer og satte fart på både dataanalysen og softwareudviklingen, og lige så nyttigt gjorde de det, der blev sendt ud, mere konsistent — færre overraskelser fra arbejde, der var blevet gjort en anelse forskelligt hver gang.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/da/portfolio/developed-a-data-analytics-reporting-system-increasing-quarterly-44/","url":"https://engineer.company/da/portfolio/developed-a-data-analytics-reporting-system-increasing-quarterly-44/","title":"Har udviklet et rapporteringssystem til dataanalyse og øget den kvartalsvise softwareomsætning med 400 % gennem Python‑baserede PDF‑rapporter.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e Interessenterne fik ikke analyse i nogen rettidig, læsbar form. Dataene fandtes, men at omsætte dem til noget, man faktisk kunne træffe en beslutning ud fra, var langsomt og manuelt, så indblikket i, hvordan tingene præsterede, haltede, og de kommercielle beslutninger haltede med.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eOpgave.\u003c/strong\u003e At bygge et rapporteringssystem til dataanalyse — et, der omsatte rådata til klar, regelmæssig indsigt uden at nogen håndsamlede det hver gang — var jobbet.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eHandling.\u003c/strong\u003e Et rapporteringssystem genererede PDF‑rapporter i Python og automatiserede hele kæden: at trække dataene, køre analysen og præsentere det i et rent, konsistent format, interessenterne faktisk kunne læse. Pointen var regelmæssighed og klarhed — den samme professionelle rapport landede forudsigeligt, så tallene blev noget, folk kiggede på som en selvfølge frem for noget, de skulle gå ud og grave frem.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResultat.\u003c/strong\u003e Den rapportering er det, der drev den kvartalsvise softwareomsætning op med 400 %. At gøre analysen bedre og hurtigere var ikke en back‑office‑finesse — sæt klare, rettidige tal foran de folk, der træffer kommercielle beslutninger, og beslutningerne bliver bedre, og her viste det sig direkte på omsætningen.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/da/portfolio/automated-data-processing-tasks-using-shell-scripting-pl-45/","url":"https://engineer.company/da/portfolio/automated-data-processing-tasks-using-shell-scripting-pl-45/","title":"Har automatiseret databehandlingsopgaver med shell‑scripting, PL/pgSQL, Python og Transact‑SQL og øget produktiviteten og effektiviteten.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e Der var en stabil mængde tilbagevendende databehandlingsarbejde, der blev lavet i hånden. Manuelt dataarbejde har to problemer på én gang: det æder tid, og det er inkonsistent — lav den samme opgave i hånden nok gange, og den bliver gjort en anelse forskelligt, og nogle af de forskelle er fejl.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eOpgave.\u003c/strong\u003e Målet var at automatisere de opgaver, både for at få tiden tilbage og for at gøre dem pålidelige.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eHandling.\u003c/strong\u003e Databehandlingsarbejdet blev automatiseret på tværs af de databaser og systemer, det rørte, med hvad end der passede til jobbet — shell‑scripting til limen, PL/pgSQL og Transact‑SQL nede i databaserne, Python, hvor det krævede mere, end SQL kunne give. Manuelle trin blev erstattet med jobs, der kørte på samme måde hver gang, hvilket er hele pointen: et script bliver ikke træt, springer ikke et trin over og gør det ikke anderledes en fredag eftermiddag.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResultat.\u003c/strong\u003e Produktiviteten og effektiviteten gik begge op, det manuelle arbejde kom af folks bord, og databehandlingen blev konsistent og pålidelig i stedet for en kilde til små, tilbagevendende fejl.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/da/portfolio/enhanced-project-efficiency-saving-150-hours-per-month-46/","url":"https://engineer.company/da/portfolio/enhanced-project-efficiency-saving-150-hours-per-month-46/","title":"Har forbedret projekteffektiviteten og sparet 150 timer om måneden på tværs af 30 projekter ved at optimere workflows og ressourcestyring.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e På tværs af en portefølje på omkring tredive projekter blev der tabt tid hver eneste måned til arbejdsgange, der aldrig var blevet optimeret, og ressourcestyring, der var ujævn — nogle folk underudnyttede, nogle overbelastede, arbejde planlagt forskelligt fra det ene projekt til det næste.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eOpgave.\u003c/strong\u003e Målet var at gøre porteføljen mere effektiv og genvinde den tid, der gik tabt måned efter måned.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eHandling.\u003c/strong\u003e De tredive projekter blev gennemgået, med arbejdsgangene og ressourcestyringen arbejdet på samlet — flaskehalsene taget ud, arbejdsbelastningerne balanceret, så de samme få folk ikke altid var flaskehalsen, og standardiseret, hvordan arbejdet blev planlagt og kørt, så hvert projekt ikke var sit eget særtilfælde. Tredive projekter, der hver taber lidt tid, løber op; rettelsen handlede mest om at gøre de gode vaner konsistente frem for at opfinde noget smart.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResultat.\u003c/strong\u003e Ændringerne sparede omkring 150 timer om måneden på tværs af porteføljen. Det er en tilbagevendende månedlig besparelse, ikke en engangs — tredive projekter, der kører slankere, måned ud og måned ind.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/da/portfolio/managed-a-team-delivering-it-support-data-recovery-47/","url":"https://engineer.company/da/portfolio/managed-a-team-delivering-it-support-data-recovery-47/","title":"Har ledet et team, der leverede IT‑support, datagendannelse og hardwarereparation til over 1.000 kunder og sikret service i høj kvalitet.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e Virksomheden var stedet, en stor base af kunder kom til, når deres IT gik i stykker — support, datagendannelse, hardwarereparation, hele spektret. At møde den slags stabile, uglamourøse efterspørgsel handler ikke om heltemod; det handler om at have et team, der kører godt dag efter dag, for arbejdet holder aldrig rigtig op med at komme.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eOpgave.\u003c/strong\u003e At lede det team, der leverede det hele, var jobbet, og at holde kvaliteten konsistent, om det så var en stille uge, eller alt kom på én gang.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eHandling.\u003c/strong\u003e Teamet kørte IT‑support, datagendannelse og hardwarereparation for over tusind kunder. En stor del af det var organiseringen nedenunder — at sikre, at arbejde blev samlet op og ikke tabt, at sætte en standard for, hvad \u0026ldquo;repareret\u0026rdquo; faktisk betød, så folk ikke fik halve reparationer tilbage, og at holde teamet effektivt, når køen var lang. Datagendannelse især er arbejde, man ikke kan være ligeglad med; det er som regel nogens billeder eller deres forretning, der ligger på det drev, og de har allerede en dårlig dag, når de når frem til dig.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResultat.\u003c/strong\u003e Teamet betjente over tusind kunder og opbyggede et ægte omdømme for pålidelig service. I den slags forretning er omdømmet alt — folk kommer tilbage, og de fortæller andre om det, netop fordi du sidste gang, noget gik i stykker, faktisk fik det ordnet.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/da/portfolio/configured-and-deployed-1-000-wi-fi-routers-48/","url":"https://engineer.company/da/portfolio/configured-and-deployed-1-000-wi-fi-routers-48/","title":"Har konfigureret og idriftsat 1.000 Wi‑Fi‑routere og forbedret netværkstilgængeligheden og -ydeevnen for kunderne.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e Kunder havde brug for trådløst, der bare virkede, og det kom ned til at konfigurere og rulle et stort antal Wi‑Fi‑routere ud — og gøre det på den samme omhyggelige måde hver gang, for en router sat sjusket op er enten usikker eller langsom, og som regel finder man ud af hvilken en senere.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eOpgave.\u003c/strong\u003e At konfigurere og udrulle de routere for at give kunderne bedre netværksadgang og -ydeevne var jobbet.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eHandling.\u003c/strong\u003e Tusind Wi‑Fi‑routere blev konfigureret og udrullet. Kunsten ved det antal er at standardisere opsætningen — en konsistent, sikker, fornuftig konfiguration — frem for at tune hver enkelt fra bunden på dagen, for tusind håndlavede routere er tusind forskellige ting at supportere senere. Så de blev sat op for sikkerhed og ydeevne på samme måde hver gang og rullet pålideligt ud på tværs af kundelokationer.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResultat.\u003c/strong\u003e De tusind routere gav kunderne pålideligt trådløst — bedre adgang, bedre ydeevne — og gjorde det konsistent, fordi opsætningen var standard frem for improviseret. En router, ingen skal tænke over igen, er målet; de fleste af disse nåede dertil.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/da/portfolio/managed-4-000-computer-repairs-ensuring-rapid-and-49/","url":"https://engineer.company/da/portfolio/managed-4-000-computer-repairs-ensuring-rapid-and-49/","title":"Har håndteret 4.000 computerreparationer og sikret hurtig og effektiv løsning af hardware- og softwareproblemer.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e Der kom en konstant strøm af computerreparationer ind — fire tusind af dem over tid — og hver eneste var en, der ventede på at få sin maskine tilbage og komme videre med sin dag. Hardwarefejl, softwarefejl, hele blandingen, og kunderne bedømte forretningen på, hvor hurtigt og hvor ordentligt de blev rettet.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eOpgave.\u003c/strong\u003e At håndtere de reparationer var jobbet — at holde problemer løst hurtigt og, lige så vigtigt, korrekt.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eHandling.\u003c/strong\u003e Fire tusind computerreparationer blev håndteret — hardware- og softwarefejlene diagnosticeret, arbejdsgangen organiseret, så maskiner bevægede sig igennem i stedet for at hobe sig op, og kvaliteten holdt, så en reparation faktisk blev gjort rigtigt frem for sendt ud igen for at fejle på ny næste uge. En reparation, der kommer tilbage, er værre end en langsom en; den koster kunden en tur til, og den koster forretningen tilliden. Så gennemløbet betød noget, men aldrig på bekostning af at rette den første gang.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResultat.\u003c/strong\u003e Alle fire tusind blev løst, og hurtigt. Folk fik deres maskiner tilbage i funktion og kom videre med tingene, og virksomhedens navn for pålidelig service holdt — hvilket i en reparationsforretning er hele forretningen.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/da/portfolio/administered-100-bare-bone-servers-physical-networks-and-50/","url":"https://engineer.company/da/portfolio/administered-100-bare-bone-servers-physical-networks-and-50/","title":"Har administreret 100 barebone‑servere, fysiske netværk og IP‑telefonisystemer og sikret en robust infrastruktur til virksomhedens vækst.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e Under alt, hvad virksomheden lavede, lå det fysiske — servere, de faktiske netværk, IP‑telefonien — og det skulle bare køre. Det lag er usynligt, når det virker, og ekstremt synligt i det øjeblik, det ikke gør, og virksomhedens vækst hvilede på, at det holdt sig pålideligt.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eOpgave.\u003c/strong\u003e At administrere den infrastruktur og holde den stabil, efterhånden som virksomheden voksede, var jobbet.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eHandling.\u003c/strong\u003e Hundrede barebone‑servere sammen med de fysiske netværk og IP‑telefonisystemerne blev passet — opsætningen, vedligeholdelsen, fejlfindingen, når noget gik galt. Barebone‑servere betyder, at man har med hardwaren direkte at gøre, så der er en hands‑on, fysisk side af det: kablingen, kasserne, telefonsystemet, som alle bemærker i det sekund, et opkald falder. Jobbet var at holde det hele kedeligt, i den gode forstand.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResultat.\u003c/strong\u003e Serverne, netværkene og telefonien kørte pålideligt, og det pålidelige fysiske fundament er det, der lod virksomheden blive ved med at vokse, uden at grunden flyttede sig under den.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/da/portfolio/developed-100-web-applications-using-html-html5-css-51/","url":"https://engineer.company/da/portfolio/developed-100-web-applications-using-html-html5-css-51/","title":"Har udviklet 100 webapplikationer med HTML/HTML5, CSS/SCSS, Django, WordPress og Joomla og sikret en alsidig online tilstedeværelse.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e Kunder ville have webapplikationer, og de ville have vidt forskellige ting — forskellige størrelser, forskellige budgetter, forskellige niveauer af \u0026ldquo;få mig bare online\u0026rdquo; over for \u0026ldquo;byg mig noget skræddersyet.\u0026rdquo; At møde det betød at være alsidig frem for at tvinge hver kunde ned ad den samme teknologi.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eOpgave.\u003c/strong\u003e At bygge webapplikationer, der gav hver kunde en alsidig, effektiv online tilstedeværelse, var jobbet.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eHandling.\u003c/strong\u003e Hundrede webapplikationer blev bygget, og pointen var at matche værktøjet til opgaven frem for at have en favorit. Hvor en kunde havde brug for noget skræddersyet, var det HTML/HTML5, CSS/SCSS og Django; hvor de havde brug for noget mere standard, som de også selv kunne håndtere, var WordPress eller Joomla det hurtigere, mere fornuftige svar. En del af færdigheden var at vide, hvad der var hvad — at tale en kunde fra et skræddersyet build, de ikke havde brug for, eller til et, de havde.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResultat.\u003c/strong\u003e De hundrede applikationer gav kunderne en varieret, kompetent online tilstedeværelse, hver leveret på den teknologi, der faktisk passede til den. At matche tilgangen til kunden frem for omvendt er det, der gjorde dem effektive frem for bare leveret.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/da/portfolio/designed-30-websites-delivering-unique-and-flexible-solutions-52/","url":"https://engineer.company/da/portfolio/designed-30-websites-delivering-unique-and-flexible-solutions-52/","title":"Har designet 30 websites og leveret unikke og fleksible løsninger ved at konvertere Photoshop‑designs til HTML.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e Kunder kom ind med et udseende, de ville have — ofte et færdigt visuelt design — og havde brug for et website bygget trofast ud fra det. Afstanden mellem en designfil og et fungerende site er der, hvor en masse kvalitet vindes eller tabes: det er nemt at sende noget ud, der er nogenlunde rigtigt og subtilt forkert.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eOpgave.\u003c/strong\u003e At designe siderne og konvertere designene til nøjagtige, fleksible implementeringer var jobbet.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eHandling.\u003c/strong\u003e Tredive websites blev designet og Photoshop‑designene konverteret til HTML i hånden. Trofast var standarden — mellemrummene, typografien, de detaljer, designeren faktisk mente, ikke en tilnærmelse af dem — men det var fleksibel også, for et site, der matcher mockuppen pixel for pixel og så falder fra hinanden i det øjeblik, indholdet ændrer sig, er ikke rigtig bygget godt. Så målet var markup, der forblev tro mod designet og forblev vedligeholdelig bagefter.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResultat.\u003c/strong\u003e De tredive sites matchede deres designs og forblev brugbare — distinktive, forfinede webtilstedeværelser, der ikke gik i stykker første gang, nogen redigerede dem. Trofast mod designet og stadig vedligeholdelig er den balance, der betød noget, og det er der, disse landede.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/da/portfolio/administered-40-websites-on-ubuntu-linux-hosting-servers-53/","url":"https://engineer.company/da/portfolio/administered-40-websites-on-ubuntu-linux-hosting-servers-53/","title":"Har administreret 40 websites på Ubuntu Linux‑hostingservere med Apache og Nginx og sikret høj tilgængelighed og ydeevne.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e Der var en portefølje af live websites, der skulle blive oppe og blive hurtige — og hosting er endnu et af de jobs, der er usynlige, indtil et site går ned, hvorefter det er det eneste, nogen bekymrer sig om.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eOpgave.\u003c/strong\u003e At administrere de sites og holde dem højt tilgængelige og hurtige var jobbet.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eHandling.\u003c/strong\u003e Fyrre websites kørte på Ubuntu Linux‑hostingservere, på en blanding af Apache og Nginx — konfigurationen, ydeevnetuningen, den løbende vedligeholdelse for at holde dem pålidelige under reel trafik. Reel trafik er det afgørende: et site, der er fint, når ingen bruger det, og vælter, når de gør, er ikke blevet administreret, det er bare blevet ladt i fred. Så arbejdet var at holde dem sunde under faktisk belastning.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResultat.\u003c/strong\u003e Alle fyrre kørte med høj tilgængelighed og god ydeevne, hvilket gav kunderne hosting, de ikke behøvede at tænke over. Stabil og pålidelig under reel brug er hele pointen med hosting, og det er det, disse leverede.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/da/portfolio/engineered-600-pl-pgsql-based-etl-elt-pipelines-54/","url":"https://engineer.company/da/portfolio/engineered-600-pl-pgsql-based-etl-elt-pipelines-54/","title":"Har udviklet 600 PL/pgSQL‑baserede ETL/ELT‑pipelines for at strømline komplekse databehandlingsworkflows på tværs af flere PostgreSQL‑udviklings- og produktionsmiljøer.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e Organisationen håndterede store mængder transaktions- og analysedata på tværs af flere PostgreSQL‑udviklings- og produktionsmiljøer. De eksisterende datapipelines var fragmenterede, manglede konsistens og forårsagede ydeevneflaskehalse, hvilket førte til forsinkelser i forretningskritisk rapportering og beslutningstagning.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eOpgave.\u003c/strong\u003e Opgaven var at designe og implementere robuste, skalerbare og effektive ETL/ELT‑pipelines med PL/pgSQL for at strømline komplekse workflows til dataindtagelse, -transformation og -indlæsning. Et nøglemål var at forbedre forespørgselsydeevnen og sikre dataintegritet på tværs af alle miljøer.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eHandling.\u003c/strong\u003e Over 600 PL/pgSQL‑baserede ETL/ELT‑pipelines blev udviklet til at automatisere udtræk, transformation og indlæsning af data fra forskellige kilder. Partitionerede tabeller og materialized views blev udnyttet for at optimere læseydeevnen, primary- og foreign key‑constraints anvendt for at bevare referentiel integritet, unikke og composite‑indeks designet for at fremskynde JOIN‑operationer, exception handling og transaktionskontrol indbygget for fejltolerance samt inkrementelle loads aktiveret via change data capture (CDC) og timestamp‑baserede deltaer, hvilket reducerede behandlingstiden med over 60 %. Automatiserede logging- og revisionsprocedurer blev også udviklet.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResultat.\u003c/strong\u003e Den nye ETL/ELT‑ramme forbedrede markant konsistensen, pålideligheden og ydeevnen af databehandlingsworkflows: en 35 % reduktion i den gennemsnitlige pipeline‑udførelsestid, over 50 % øget gennemløb med næsten realtids‑datatilgængelighed, over 90 % færre transformationsfejl gennem bedre constraint‑håndhævelse og validering samt forbedret vedligeholdelighed og skalerbarhed med minimal omarbejde ved fremtidige datamodelændringer.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/da/portfolio/architected-developed-implemented-supported-infrastructure-data-processing-and-55/","url":"https://engineer.company/da/portfolio/architected-developed-implemented-supported-infrastructure-data-processing-and-55/","title":"Arkitekt, udviklet, implementeret, understøttet infrastruktur, databehandling og kortapplikationen i 2 år uden pause, uden weekender, helligdage eller ferie, 10‑14 timer om dagen.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e En green energy‑startup i en tidlig fase var afhængig af én platform til at spore, overvåge og optimere vedvarende energiaktiver, men havde hverken et dedikeret infrastrukturteam eller en etableret ingeniørorganisation til at bygge og drive den. Hele det tekniske fundament — cloud‑infrastruktur, datapipelines og den kundevendte GIS‑kortapplikation — skulle skabes og holdes kørende uafbrudt, på et marked hvor enhver nedetid eller datamangel direkte svækkede kundernes tillid og omsætningen.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eOpgave.\u003c/strong\u003e Opgaven var egenhændigt at arkitektere, bygge og drive hele systemet fra ende til anden — på tværs af platform- og dataingeniørarbejde, DevOps og site reliability. Ud over at skrive softwaren betød det at eje produktionsmiljøet: at provisionere og hærde infrastruktur, designe databehandlingslaget der fodrede kortet, og garantere at applikationen forblev tilgængelig døgnet rundt for en voksende kundebase — alt sammen inden for en hurtig startups rammer og ubønhørlige tempo.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eHandling.\u003c/strong\u003e I to år blev infrastrukturen, datapipelines og kortapplikationen designet, implementeret og understøttet uden afbrydelse — uden weekender, helligdage eller ferie, ofte ti til fjorten timer om dagen. En pragmatisk, modulær arkitektur blev valgt for at holde en enmandsdrift vedligeholdelsesvenlig, med automatiseret provisionering, monitorering og alarmering, så problemer kunne opdages og løses hurtigt. Databehandlingen blev løbende optimeret for pålidelighed og ydeevne, releases blev udrullet trinvist, og hvert lag — fra servere til det brugervendte kort — blev personligt vedligeholdt og forbedret ud fra reel kundeanvendelse.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResultat.\u003c/strong\u003e Platformen forblev konstant tilgængelig og udviklede sig fra en skrøbelig tidlig prototype til produktets pålidelige rygrad og bar virksomheden gennem dens kritiske vækstfase alene på styrken af én ingeniørs ejerskab. Denne praktiske forvaltning holdt infrastruktur, data og kortapplikation pålidelig nok til at understøtte mersalg, datalicensering og tiltrækning af nye kunder og demonstrerede en sjælden grad af engagement, bredde og ansvar fra ende til anden på tværs af hele stakken.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/da/portfolio/optimized-budget-costs-10-times-with-zero-loss-56/","url":"https://engineer.company/da/portfolio/optimized-budget-costs-10-times-with-zero-loss-56/","title":"Har optimeret budgetomkostningerne 10 gange uden tab af produktivitet for den saudiarabiske virksomhed ved at nytænke den samlede infrastruktur, fjerne unødvendige tjenester og flytte væk fra AWS‑skyen.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e En virksomhed med base i Saudi‑Arabien slæbte rundt på slemt oppustede infrastrukturomkostninger. Deres AWS‑setup var blevet overdimensioneret og havde samlet tjenester, de ikke længere brugte, så cloud‑regningen var drevet fuldstændig ud af proportion med, hvad forretningen faktisk havde brug for. Det er en almindelig historie — ingen sætter sig for at overforbruge, det aflejrer sig bare, når ingen holder øje med måleren.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eOpgave.\u003c/strong\u003e Opgaven var at skære omkostningerne betydeligt ned uden at miste produktivitet, hvilket betød at gentænke infrastrukturen ordentligt frem for at beskære i kanterne — kantbeskæring flytter sjældent en regning, der er strukturelt for stor.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eHandling.\u003c/strong\u003e Så arbejdet gik fra ende til anden. Først kom en audit af, hvad der faktisk blev brugt — hvilket er der, de duplikerede og unødvendige tjenester viser sig — og de blev skåret væk. Så blev det, der var tilbage, right‑sizet til at matche reel efterspørgsel i stedet for de worst‑case‑gæt, det oprindelige setup var bygget på. Og det store træk var at flytte workloads helt væk fra AWS, over på et mere omkostningseffektivt hosting‑arrangement — gjort omhyggeligt, i etaper, så den kørende forretning aldrig mærkede migreringen ske under sig.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResultat.\u003c/strong\u003e Budgetomkostningerne faldt omkring ti gange, uden tab af produktivitet — den samme kapabilitet til en brøkdel af, hvad de havde betalt. Det frigjorde et reelt beløb, der stille og roligt var sivet ud i en overdimensioneret cloud‑regning måned efter måned, hvilket for forretningen var penge direkte tilbage på bundlinjen.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/da/portfolio/architected-a-layered-maritime-platform-separating-a-next-57/","url":"https://engineer.company/da/portfolio/architected-a-layered-maritime-platform-separating-a-next-57/","title":"Har arkitekteret en lagdelt maritim platform, der adskiller en Next.js PWA‑frontend, et Go (Huma/Fiber) API og et PostgreSQL‑funktionslag og holder al forretningslogik i databasen.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e NextMariner skulle være en maritim platform — professionelt netværk, virksomhedsanmeldelser, sponsoreret uddannelse — og det var et ungt produkt, hvilket er en pæn måde at sige, at kravene ville flytte sig en hel del. Det, der skulle undgås, var en arkitektur, hvor en ændret forretningsregel betød, at man skulle røre frontenden, API\u0026rsquo;et og databasen på én gang. På en lille kodebase, der vokser hurtigt, er det den slags kobling, der gør en to‑linjers ændring til en hel eftermiddag.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eOpgave.\u003c/strong\u003e Som arkitekt var beslutningen på forhånd, hvor hver slags logik boede, med grænser tydelige nok til at holde under pres, i stedet for at blive udvisket første gang nogen havde travlt.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eHandling.\u003c/strong\u003e Det landede på tre lag, ét job hver. Next.js‑frontenden står for præsentation og interaktivitet og intet andet. Go‑API\u0026rsquo;et — Huma oven på Fiber — er bevidst tyndt: det router, validerer requesten, laver sikkerhedsfiltreringen og orkestrerer, men det rummer slet ingen forretningslogik. Forretningslogikken bor i PostgreSQL‑funktioner, som samler det fulde resultat og giver det tilbage, som API\u0026rsquo;et videresender. Så når en regel ændrer sig, ændrer den sig i ét lag, i SQL, og de to andre behøver ikke vide det. Grænserne blev skrevet ned og håndhævet i review, for en konvention, ingen holder øje med, holder op med at være en.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResultat.\u003c/strong\u003e Tingen forblev nem at holde i hovedet. Forretningslogikken sidder ét sted, man faktisk kan revidere, API\u0026rsquo;et er en kedelig adapter på den gode måde, og frontenden er ligeglad, når skemaet flytter sig under den. Den adskillelse er det, der lod produktet blive ved med at skrue funktioner på, uden at arkitekturen stille og roligt rådnede.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/da/portfolio/designed-a-json-passthrough-architecture-where-postgresql-functions-58/","url":"https://engineer.company/da/portfolio/designed-a-json-passthrough-architecture-where-postgresql-functions-58/","title":"Har designet en JSON passthrough‑arkitektur, hvor PostgreSQL‑funktioner returnerer komplet JSON, som Go‑API'et videresender uændret, hvilket eliminerer mellemliggende unmarshalling og afkobler frontenden fra skemaændringer.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e Den sædvanlige måde, data kommer fra en database til en browser, er et stafetløb af transformationer. Databasen giver API\u0026rsquo;et rækker, API\u0026rsquo;et unmarshaller dem til structs, omformer dem, serialiserer dem tilbage til JSON, og først da ryger de ud. Hvert af de spring er kode, man skriver, kode, man tester, og endnu et sted, hvor API\u0026rsquo;ets idé om dataene og databasens idé om dem kan glide fra hinanden.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eOpgave.\u003c/strong\u003e Idéen var at springe stafetløbet over. Hvis databasen kunne returnere det færdige svar, kunne API\u0026rsquo;et bare sende det videre, og frontenden kunne afhænge direkte af databasens form i stedet for af en håndholdt kopi af den, der lå i Go.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eHandling.\u003c/strong\u003e Så det blev bygget som en ren passthrough. PostgreSQL‑funktionerne samler hele svaret som JSON — formningen er en SQL‑opgave, gjort der, hvor dataene i forvejen er. Go‑handleren tager det tilbage som json.RawMessage og videresender det uændret; den dekomponerer det aldrig, re‑encoder det aldrig. En lille QueryJSON‑helper gjorde det mønster til vejen med mindst modstand frem for noget, man skulle huske at gøre. Det, der faldt fra, var alt det mellemliggende maskineri, et konventionelt lagdelt API samler op — DTO\u0026rsquo;erne, mapperne, svar‑structene.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResultat.\u003c/strong\u003e Handler‑koden blev dramatisk kortere, og vigtigere endnu holdt frontenden op med at være koblet til Go. Skift, hvad en funktion returnerer, og den nye form flyder direkte igennem til klienten, uden at nogen redigerer en linje handler‑kode. Færre bevægelige dele, og en hel kategori af drift mellem lag findes simpelthen ikke her.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/da/portfolio/designed-an-organization-context-switching-system-with-client-59/","url":"https://engineer.company/da/portfolio/designed-an-organization-context-switching-system-with-client-59/","title":"Har designet et system til at skifte organisationskontekst med client‑localStorage og server‑side cookie‑spejling, så brugere kan agere som administrerede organisationer under håndhævelse af least‑privilege‑autorisation.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e På NextMariner kan en maritim professionel administrere organisationer — virksomheder, akademier — der ikke har deres egne logins. Personen er kontoen; organisationen er noget, de agerer på vegne af. Så en bruger skal kunne bevæge sig gennem hele appen som enhver organisation, de administrerer, og skifte mellem dem frit, og den bekvemmelighed må ikke blive til et hul i autorisationen.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eOpgave.\u003c/strong\u003e Kontekstskift skulle være hurtigt og upåfaldende for brugeren og samtidig sikre, at den aktive kontekst aldrig af sig selv kunne give nogen adgang, de ikke var berettiget til.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eHandling.\u003c/strong\u003e En OrganizationContext håndterer det, med lagring på begge sider. På klienten er localStorage kilde til sandhed for, hvilken organisation man aktuelt agerer som, så skiftet er øjeblikkeligt — ingen rundtur. En server‑side cookie spejler det, så server‑renderede sider løser den samme kontekst under SSR; der er en getServerViewMode på serveren, der læser den. Det vigtige er, at intet af det bliver stolet på til adgangsbeslutninger. Autorisation genkontrolleres på serveren ved hver request. Frontend‑konteksten er der for oplevelsen — at vise dig det rigtige — og serveren er den eneste autoritet på, hvad du må.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResultat.\u003c/strong\u003e En bruger kan agere som enhver organisation, de administrerer, uden friktion, og grænsefladen holder sig i sync på både klient og server. Men fordi rettigheder verificeres server‑side hver gang, svækker intet af den bekvemmelighed sikkerheden. En, der pillede ved det, der ligger i localStorage, ændrer, hvad deres eget UI viser dem, og intet mere — serveren siger stadig nej.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/da/portfolio/migrated-the-http-api-from-fiber-to-huma-60/","url":"https://engineer.company/da/portfolio/migrated-the-http-api-from-fiber-to-huma-60/","title":"Har migreret HTTP‑API'et fra Fiber til Huma v2 og opnået automatisk request‑validering og OpenAPI‑modellering på tværs af alle endpoints.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e API\u0026rsquo;et startede sit liv på Fiber, med request‑validering skrevet ud i hånden, endpoint for endpoint. Det er fint, når der er en håndfuld endpoints. Det holder op med at være fint, efterhånden som fladen vokser: den håndskrevne validering bliver til en vedligeholdelsesskat, og små inkonsistenser sniger sig ind, fordi hvert endpoints tjek er dets eget lille særtilfælde. Og der var ingen enkelt beskrivelse af API\u0026rsquo;ets form nogen steder.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eOpgave.\u003c/strong\u003e Målet var validering, der kom fra typerne i stedet for fra håndskrevne tjek, og en egentlig kontrakt, der beskrev API\u0026rsquo;et — uden at stoppe op for at lave en big‑bang‑omskrivning.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eHandling.\u003c/strong\u003e HTTP‑laget flyttede over på Huma v2, oven på Fiber, så den eksisterende runtime blev bevaret. Hvert endpoint får input- og output‑structs, og Huma genererer request‑valideringen og respons‑modelleringen ud fra de typer. En OpenAPI‑beskrivelse falder ud af det gratis, hvilket betyder, at dokumentationen følger koden i stedet for at rådne i en wiki. Alt nyt blev skrevet mod Huma og de eksisterende ruter migreret over, med præcis to endpoints efterladt på rå Fiber — WebSocket‑dem, hvor man reelt vil have socket\u0026rsquo;en, og Humas request/response‑model ikke passer.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResultat.\u003c/strong\u003e Nye endpoints får validering og opdateret dokumentation, uden at nogen laver ekstra arbejde for det, og en hel klasse af request‑fejl — \u0026ldquo;nå ja, vi glemte at tjekke det felt her\u0026rdquo;-slagsen — forsvandt. Den typede kontrakt gjorde API\u0026rsquo;et både sikrere at ændre og lettere at give videre til en anden, for typerne fortæller dig, hvad et endpoint forventer.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/da/portfolio/built-a-request-schema-validation-contract-with-automated-61/","url":"https://engineer.company/da/portfolio/built-a-request-schema-validation-contract-with-automated-61/","title":"Har bygget en request‑schema‑valideringskontrakt med automatiserede guards, der fanger uoverensstemmelser i payloads mellem frontend og backend, før de når produktion.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e Frontend og backend bevæger sig i deres eget tempo, og deres antagelser om en request‑payload kan glide fra hinanden, uden at nogen bemærker det. Måden, man som regel opdager det på, er et 422 i browseren — efter uoverensstemmelsen allerede er udgivet, hvilket er det dyreste tidspunkt at få det at vide på.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eOpgave.\u003c/strong\u003e Målet var de uoverensstemmelser fanget af pipelinen, automatisk, før de kunne nå en bruger.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eHandling.\u003c/strong\u003e Et kontrakt‑tjek kører i CI — api‑contract‑check.sh — som sammenligner det, frontenden sender, med det, API\u0026rsquo;et faktisk forventer, og får buildet til at fejle ved enhver afvigelse. Der er en schema‑probe under det, som tjekker de rigtige former frem for en beskrivelse af dem. Det dækker bevidst de tilfælde, hvor drift kan lide at gemme sig: valgfrie body‑felter, hvor \u0026ldquo;mangler\u0026rdquo; og \u0026ldquo;null\u0026rdquo; bliver forvekslet, og query‑parameter‑enums, hvor de to sider stille og roligt kan være uenige om de tilladte værdier. I stedet for at stole på, at folk holder frontend og backend i takt i hånden, gør tjekket det.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResultat.\u003c/strong\u003e De to halvdele forbliver i takt. En payload‑uoverensstemmelse får et build til at fejle i stedet for at overraske en bruger, hvilket tog en tilbagevendende og oprigtigt irriterende klasse af fejl af bordet — den slags, der er usynlig i code review og først dukker op i runtime. Og fordi det kører i pipelinen, får en bidragyder hurtigt besked, når en ændring ville bryde kontrakten, mens rettelsen stadig er billig.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/da/portfolio/implemented-startup-mail-provider-validation-across-three-providers-62/","url":"https://engineer.company/da/portfolio/implemented-startup-mail-provider-validation-across-three-providers-62/","title":"Har implementeret validering af mailudbyder ved opstart på tværs af tre udbydere (SendGrid, SMTP2GO, Azure ACS) med miljøbevidst adfærd — logning i udvikling, fejl ved opstart i staging og produktion.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e E‑mail vejer tungt på NextMariner — verificering, notifikationer, de ting en bruger faktisk venter på. Og en mailudbyder er præcis den slags afhængighed, der fejler lydløst: konfigurationen ser fin ud, appen booter, og du opdager først, at noget er galt, når et rigtigt menneske aldrig får den besked, det blev lovet. Det er den værste måde at få det at vide på.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eOpgave.\u003c/strong\u003e Appen skulle ved opstart tjekke, at mail rent faktisk virkede, og være højlydt om det i de miljøer, hvor det betyder noget, uden at gøre en rutinemæssig lokal kørsel til en plage.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eHandling.\u003c/strong\u003e Så udbyder‑validering gik ind i boot‑sekvensen, bag et MAIL_VALIDATE_ON_START‑flag. Den sender en rigtig test gennem udbyder‑stakken — SendGrid som primær, med SMTP2GO og Azure Communication Services bagved som fallbacks — og hvordan den reagerer afhænger af, hvor den kører. I develop logger den bare en advarsel og fortsætter; ingen vil have deres laptop til at nægte at starte, fordi en sandkasse‑nøgle er udløbet. I staging og produktion er en fejl fatal: processen afslutter frem for at deploye et build, der ikke kan sende mail. Selve afsendelsen går gennem en SSRF‑beskyttet klient med et 30‑sekunders timeout, og den asynkrone leveringssti har sine egne retries og backoff, så et øjebliks udfald ikke taber en besked.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResultat.\u003c/strong\u003e En hel kategori af lydløs fejl flyttede fra \u0026ldquo;en bruger opdager det dage senere\u0026rdquo; til \u0026ldquo;deployet stopper.\u0026rdquo; Hvor brudt mail er et reelt problem, kan det ikke slippe igennem; på en udviklers maskine holder det sig ude af vejen. Samme tjek, forskellig lydstyrke afhængigt af hvem der kigger med.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/da/portfolio/designed-a-postgresql-function-first-data-layer-across-63/","url":"https://engineer.company/da/portfolio/designed-a-postgresql-function-first-data-layer-across-63/","title":"Har designet et function‑first datalag i PostgreSQL på tværs af platformens domæneskemaer (identity, organization, review, message, notification med flere), hvor al dataadgang eksponeres gennem stored functions.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e Forretningslogik har det med at lække. Lidt ender i API\u0026rsquo;et, lidt i noget SQL, en handler kører inline, og før længe er den samme regel skrevet på to‑tre lidt forskellige måder, og der er ingen steder, man kan pege hen og sige \u0026ldquo;det her er, hvad systemet gør med sine data.\u0026rdquo; Det er sådan, fejl og sikkerhedshuller kommer ind.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eOpgave.\u003c/strong\u003e Målet var ét hjem til det hele: hver læsning og skrivning gennem databasen, API\u0026rsquo;et en tynd adapter, der ikke kender forretningsreglerne, og det hele muligt at låse ned til.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eHandling.\u003c/strong\u003e Datalaget er function‑first. Skemaet er delt op efter domæne — identity, organization, review, message, notification og et par dusin mere — og hver operation, appen kan udføre, er en PostgreSQL‑funktion, den kalder; der er slet ingen direkte tabeladgang fra Go. Så håndhæver databasen det. Den rolle, API\u0026rsquo;et logger ind som, mariner, har EXECUTE på app‑funktionerne og USAGE på skemaerne og intet andet — ingen SELECT, ingen INSERT, ingen måde at røre en tabel direkte. Funktionerne kører SECURITY DEFINER, ejet af en separat non‑login function_owner‑rolle med en pinned search_path, og superuser‑kontoen holdes reserveret til migrationer og cron, langt væk fra den kørende app.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResultat.\u003c/strong\u003e Logikken bor ét sted, man faktisk kan revidere, API\u0026rsquo;et forbliver tyndt og kedeligt på den gode måde, og adgangsgrænsen håndhæves af Postgres selv frem for af, at alle husker reglerne. Hvis API\u0026rsquo;et på en eller anden måde blev kompromitteret, kunne det stadig ikke gøre noget, funktionerne ikke tillader.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/da/portfolio/adopted-uuid-v7-time-ordered-identifiers-postgresql-18-64/","url":"https://engineer.company/da/portfolio/adopted-uuid-v7-time-ordered-identifiers-postgresql-18-64/","title":"Har indført tidsordnede UUID v7‑identifikatorer (PostgreSQL 18) som entitetsnøgler for at reducere fragmentering af B‑tree‑indeks og øge forespørgselshastigheden.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e Hver entitet har brug for et unikt id, og reflekvalget er en tilfældig UUID. Problemet er, at tilfældige id\u0026rsquo;er lander over det hele i et B‑tree‑indeks. Inserts spreder sig, indekset fragmenterer, og efterhånden som tabeller vokser, betaler både skrivninger og range‑scans for det. På en platform, der er ment til at blive ved med at vokse, er det en langsom lækage, man helst ikke vil bygge ind.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eOpgave.\u003c/strong\u003e Bevare en UUID\u0026rsquo;s globale unikhed, men slippe af med den fragmentering, tilfældigheden fører med sig.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eHandling.\u003c/strong\u003e Standarden blev UUID v7, som er tidsordnet — de førende bits er et tidsstempel, så nye rækker sorterer ind i indekset i stedet for at drysse det til. PostgreSQL 18 har det nativt som uuidv7(), pakket ind i en lille uuid_generate_v7()-funktion, så det samme kald opfører sig rent på Azures Flexible Server, og gjort til default for entiteters primærnøgler på tværs af skemaet. Intet eksotisk ved det; det er den slags beslutning, der er billig, hvis man træffer den tidligt, og en plage at eftermontere senere.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResultat.\u003c/strong\u003e Id\u0026rsquo;er forblev globalt unikke, indekset holdt op med at fragmentere, som tilfældige UUID\u0026rsquo;er får det til, og tidsordnede inserts og range‑forespørgsler blev hurtigere — jævnt, på tværs af hver tabel, uden at nogen skulle tænke over det igen. Som en bonus ender hver entitet med en nøgle, man kan sortere efter tid gratis.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/da/portfolio/implemented-a-catalogue-driven-deep-merge-for-stored-65/","url":"https://engineer.company/da/portfolio/implemented-a-catalogue-driven-deep-merge-for-stored-65/","title":"Har implementeret en katalogdrevet deep‑merge for lagrede JSON‑præferencer, hvilket forhindrer nedbrud på grund af manglende nøgler, når skemaet udvikler sig.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e Platformen lagrer JSON‑præferencer — notifikationsindstillinger og den slags — som en brugers gemte værdier lagt over et sæt defaults. Den oprindelige merge gjorde det på ét niveau. Problemet dukker op senere: tilføj en ny nøgle til defaults, og rækker gemt før den nøgle eksisterede, har den simpelthen ikke. Så læser noget klientkode det felt, får undefined og vælter — for præcis de brugere, der har været der længst.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eOpgave.\u003c/strong\u003e Det skulle være sikkert at udvikle præference‑skemaet, så det at tilføje en indstilling aldrig kunne bryde de folk, der meldte sig til, før den fandtes.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eHandling.\u003c/strong\u003e Enkelt‑niveau‑mergen blev erstattet med en deep‑merge drevet af defaults som et katalog. Defaults behandles som den autoritative liste over hver nøgle, der bør findes; brugerens gemte værdier merges rekursivt ovenpå, så alt i kataloget garanteret kommer ud til stede, uanset om det var i den gemte blob. Tilføj en nøgle til defaults, og den optræder i hver eksisterende rækkes effektive præferencer automatisk, nestede nøgler inkluderet. Det blev rullet ind gennem en migrering, så eksisterende data fik gavnen med det samme frem for at vente på at blive skrevet om.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResultat.\u003c/strong\u003e Præferencer kan vokse uden frygt. At tilføje en indstilling risikerer ikke længere et undefined‑felt‑crash i klienten, og frontenden holdt op med at have brug for defensive tjek spredt rundt om hvert sted, den læser en præference. Det gav også resten af platformen en pålidelig måde at udvide en hvilken som helst lagret JSON‑blob — mønsteret, ikke bare den ene rettelse.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/da/portfolio/built-a-python-vessel-data-scraper-marinetraffic-maritime-66/","url":"https://engineer.company/da/portfolio/built-a-python-vessel-data-scraper-marinetraffic-maritime-66/","title":"Har bygget en Python‑scraper til skibsdata (MarineTraffic, Maritime‑Database) og importeret cirka 700 maritime virksomheder som platformens centrale referencedata.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e Et maritimt netværks- og anmeldelsessite er dødt ved ankomst, hvis det er tomt. Ingen melder sig ind i et katalog uden virksomheder i. Så før nogen af de sociale funktioner betød noget, havde platformen brug for et rigtigt korpus af maritime virksomheder og skibe, der allerede sad der, klar til at blive fundet.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eOpgave.\u003c/strong\u003e Gå ud og hent de data — rigtige virksomheder, i nok skala til at føles befolket — og få dem ind i databasen på en måde, der kunne køres igen, ikke en engangs‑scrape, ingen ville kunne reproducere.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eHandling.\u003c/strong\u003e Scraperne er skrevet i Python. Én driver MarineTraffic med Playwright; en anden henter fra Maritime‑Database over async httpx; der er også en ClassNK‑fetcher. De skriver CSV\u0026rsquo;er ud, og et import‑trin renser og normaliserer dem og indlæser dem i Postgres‑skemaet gennem en task (docker‑dat‑populate‑companies), så at seede databasen er én kommando frem for en eftermiddags manuelt arbejde. Virksomhedssættet endte på omkring 700.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResultat.\u003c/strong\u003e Platformen blev lanceret med cirka 700 rigtige maritime virksomheder i sig i stedet for tomme tabeller — et katalog, der faktisk lignede noget på dag ét, og et grundlag af referencedata, som netværks-, job- og anmeldelsesfunktionerne alle kunne bygge oven på. Og fordi pipelinen er reproducerbar, er det bare at køre den igen at opdatere eller udvide den senere.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/da/portfolio/modeled-the-maritime-domain-professionals-companies-ships-jobs-67/","url":"https://engineer.company/da/portfolio/modeled-the-maritime-domain-professionals-companies-ships-jobs-67/","title":"Har modelleret det maritime domæne — professionelle, virksomheder, skibe, jobs og anmeldelser — i normaliserede PostgreSQL‑skemaer med SMALLINT‑opslagstabeller og UUID v7‑nøgler.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e Hjertet i NextMariner er et tæt maritimt domæne — professionelle, virksomheder, skibe, jobs, anmeldelser — og de her ting refererer konstant til hinanden. En professionel sejler på skibe, arbejder for virksomheder, efterlader anmeldelser; en virksomhed ejer skibe og slår jobs op. Næsten hver funktion er en forespørgsel på tværs af det net, så hvor godt dataene er modelleret, afgør, hvor godt det meste af appen performer, og hvor fornuftigt det er at udvide den.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eOpgave.\u003c/strong\u003e Det domæne skulle modelleres, så det holdt sig hurtigt og bevarede sin integritet, og så det at tilføje den næste entitetstype ikke betød at slås med skemaet.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eHandling.\u003c/strong\u003e Det er lagt ud som normaliserede PostgreSQL‑skemaer organiseret efter domæne. De mange små, stabile enumerationer — statusser, typer, kategorier — blev SMALLINT‑opslagstabeller, hvilket holder rækkerne kompakte og joins billige i stedet for at gemme tekstkoder overalt. Entiteter får UUID v7‑primærnøgler, så de er globalt unikke, men stadig tidsordnet i indekset. Én navngivningskonvention løber hele vejen igennem — flertalstabeller inde i entalsnavngivne skemaer — anvendt uden undtagelse, hvilket som en bonus undgår en masse kollisioner med reserverede ord. Og relationerne holdes oppe af rigtige foreign keys og constraints, så integritet er databasens job, ikke noget applikationen skal huske at gøre.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResultat.\u003c/strong\u003e Det, der kom ud, er en datamodel, der er konsistent og hurtig, og forudsigelig at arbejde i, fordi de samme regler holder overalt — der er ingen særtilfælde at huske. At tilføje en funktion betyder som regel at udvide skemaet med den eksisterende retning frem for imod den. Det er gulvet, resten af platformen står på.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/da/portfolio/provisioned-azure-infrastructure-as-code-with-bicep-container-68/","url":"https://engineer.company/da/portfolio/provisioned-azure-infrastructure-as-code-with-bicep-container-68/","title":"Har provisioneret Azure‑infrastruktur som kode med Bicep — Container Apps, PostgreSQL Flexible Server, Front Door/WAF og netværk — på tværs af udviklings-, staging- og produktionsmiljøer.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e NextMariner lever på Azure, og Azure lavet i hånden — klik gennem portalen, en indstilling justeret her og der — er en fælde. Det driver, ingen husker hvorfor noget er, som det er, og at genopbygge det efter en dårlig dag er langsomt og nervepirrende. Med mere end ét miljø at holde i takt bliver det kun værre.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eOpgave.\u003c/strong\u003e Læg det hele i kode, så et miljø er noget, man kan læse, reviewe og genskabe frem for en bunke manuel tilstand.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eHandling.\u003c/strong\u003e Estatet er defineret i Bicep. Hvert miljø — testing, staging, product — kommer ud af de samme templates: api\u0026rsquo;et og www kørende som Azure Container Apps på et managed environment, en PostgreSQL Flexible Server, Redis til caching, Front Door med en WAF‑politik ude foran og netværket under det (VNet, NSG, private DNS), med Log Analytics koblet på til diagnostik. Images hentes fra projektets Azure Container Registry. Fordi det hele er parametriseret, er det at rejse et nyt miljø eller ændre et eksisterende en pull request, ikke en supportsag til en selv.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResultat.\u003c/strong\u003e Miljøerne blev reproducerbare og reviderbare. Drift holdt op med at være et mysterium, fordi kilden til sandhed er koden, og at bringe infrastruktur op eller tilbage er et spørgsmål om at anvende templates frem for at huske, hvad der blev klikket sidst. Det er forskellen mellem infrastruktur, man ejer, og infrastruktur, der ejer én.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/da/portfolio/built-github-actions-ci-cd-pipelines-with-a-69/","url":"https://engineer.company/da/portfolio/built-github-actions-ci-cd-pipelines-with-a-69/","title":"Har bygget GitHub Actions CI/CD‑pipelines med et distroless produktions‑frontend‑image og promovering på tværs af flere miljøer.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e Levering bør ikke afhænge af, at nogen husker trinene, og det, der ender med at køre i produktion, bør ikke være en fed general‑purpose‑container, der bærer en shell og en package manager, den aldrig vil bruge — det er bare angrebsflade, der sidder der uden grund.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eOpgave.\u003c/strong\u003e Gør vejen fra commit til kørende‑i‑Azure automatisk, og hold produktions‑images så små og låst ned, som hver workload tillader.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eHandling.\u003c/strong\u003e Pipelinen er GitHub Actions. Separate workflows håndterer kodekvalitets‑gaten, testene og de miljøspecifikke deploys, med CodeQL, dependency review og et SBOM‑trin ved siden af, så intet når et miljø uden først at passere tjekkene. Images er multi‑stage‑builds, og basen for hver del blev valgt efter dens fortjeneste frem for ét blankt valg: frontenden sendes på et distroless image (gcr.io/distroless/cc‑debian13 — ingen shell, ingen package manager), Go‑API\u0026rsquo;et på en slank Alpine og database‑imaget på postgres‑slim. Promovering flytter et build gennem miljøerne ad en defineret rute frem for i hånden.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResultat.\u003c/strong\u003e Releases holdt op med at være et omhyggeligt manuelt ritual og blev en rutinemæssig, kedelig hændelse, hvilket er præcis, hvad man vil have fra releases. Produktions‑frontenden kører på omtrent så lidt, som man kan give den, tjekkene fanger problemer, før de lander, og \u0026ldquo;deploy\u0026rdquo; er noget, pipelinen gør, frem for noget, nogen sveder sig igennem.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/da/portfolio/authored-300-go-task-automation-targets-spanning-native-70/","url":"https://engineer.company/da/portfolio/authored-300-go-task-automation-targets-spanning-native-70/","title":"Har skrevet over 300 go‑task‑automatiseringsmål på tværs af native-, Docker- og HTTPS‑udviklingstilstande, linting, test, database og deployment.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e NextMariner er et polyglot‑monorepo — Go, TypeScript, SQL, Python, shell — og hvert af dem medbringer sin egen måde at bygge, teste, linte og køre på. Overladt til sig selv betyder det, at alle går rundt med et mentalt spikseddel af værktøjsspecifikke kommandoer, og at nytilkomne bruger deres første dag på bare at finde ud af, hvordan man får tingene til at køre.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eOpgave.\u003c/strong\u003e Giv hele projektet én hoveddør: én konsistent måde at køre hvad som helst på, uanset hvilket sprog det tilfældigvis er skrevet i.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eHandling.\u003c/strong\u003e Det er bygget ud med go‑task — et Taskfile‑lag, der er vokset til et sted nord for 340 navngivne mål på tværs af femten‑ish namespaces. Der er udviklingstilstandene (native, Docker, en HTTPS‑variant til at teste PWA og mobil), kodekvalitetssiden (lint, format, test, fix på tværs af alle sprogene), databasehåndtering og de miljøspecifikke build- og deploy‑opgaver. Der er endda en low‑memory‑tilstand til maskiner, der ikke kan undvære den RAM, det kræver at bygge frontenden på den sædvanlige måde. Pointen var aldrig at have mange tasks; den var, at man aldrig behøver at kende den underliggende kommando.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResultat.\u003c/strong\u003e Enhver kan køre task \u0026ndash;list og se hele værktøjskæden lagt frem og køre en hvilken som helst del af den på samme måde uanset, hvad der er under motorhjelmen. Onboarding blev kortere, og de små, dumme fejl — forkert flag, forkert mappe, halvt husket kommando — forsvandt for det meste. Ét mindeværdigt indgangspunkt i stedet for et dusin.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/da/portfolio/owned-end-to-end-deployments-of-the-platform-71/","url":"https://engineer.company/da/portfolio/owned-end-to-end-deployments-of-the-platform-71/","title":"Har haft ansvaret for end‑to‑end‑deployments af platformen til Azure og styret releases på tværs af udviklings-, staging- og produktionsmiljøer.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e Platformen skulle nå brugerne på tværs af flere Azure‑miljøer, og deployment er den søm, hvor infrastrukturen, build‑pipelinen og applikationen alle mødes. Det er også der, hvor en lille fejl holder op med at være en bug og bliver til et nedbrud, så det er den del, man mindst af alt vil lave i hånden og halvt efter hukommelsen.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eOpgave.\u003c/strong\u003e Deployment blev ejet fra ende til anden, så en ændring flyttede ud til hvert miljø på den samme forudsigelige måde hver gang.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eHandling.\u003c/strong\u003e Releases bevæger sig ad en fast rute — udvikling, så staging, så produktion — frem for at nogen pusher direkte til et live miljø. CI/CD‑pipelinen bygger images og sender dem, og Bicep‑templates holder målinfrastrukturen ens fra det ene miljø til det næste, så et build ikke promoveres ind i et lidt anderledes sted hver gang. Konfiguration, der er forskellig pr. miljø, holdes adskilt fra secrets, hvilket betyder, at det samme byggede artefakt kan promoveres gennem miljøerne og bare samler de rette indstillinger op, hvor det lander, i stedet for at blive bygget om for hvert.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResultat.\u003c/strong\u003e Ændringer når hvert miljø forudsigeligt, ad en defineret vej, uden ad hoc‑manuelle deploys i blandingen. At release blev til et kontrolleret, gentageligt trin i stedet for et med tilbageholdt vejrtrækning, og det er en stor del af, hvad der holdt den live platform stabil, mens den stadig ændrede sig hurtigt nedenunder.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/da/portfolio/implemented-database-backups-and-a-disaster-recovery-strategy-72/","url":"https://engineer.company/da/portfolio/implemented-database-backups-and-a-disaster-recovery-strategy-72/","title":"Har implementeret databasebackups og en disaster recovery‑strategi understøttet af infrastructure‑as‑code for hurtig, reproducerbar genopretning.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e Et produkt, der lever på sine data, har ikke råd til at miste nogen, og \u0026ldquo;der er backups et sted\u0026rdquo; er et håb, ikke en genopretningsplan. Den eneste backup, der er noget værd, er en, man ved gendanner, ind i et miljø, man ved, man kan genopbygge. NextMariner havde brug for begge halvdele af det, ikke kun den første.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eOpgave.\u003c/strong\u003e Genopretning skulle kunne garanteres — dataene og miljøet omkring dem — hurtigt, og på en måde, der faktisk kunne reproduceres frem for at improviseres på en dårlig dag.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eHandling.\u003c/strong\u003e Databasen bliver backet up med retention konfigureret, så en gendannelse kan gå til et tidspunkt frem for bare til i går nat. Miljøet omkring den er defineret som infrastructure‑as‑code i Bicep, hvilket er den stille halvdel, folk glemmer: at gendanne en database ind i et miljø, man skulle genopbygge i hånden efter hukommelsen, er ikke rigtig genopretning. Fordi begge dele er dækket, betyder det at komme tilbage at gendanne data ind i et miljø, der kan rejses fra dets templates — en procedure, ikke en kamp.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResultat.\u003c/strong\u003e Dataene kan genoprettes, og platformen kan bringes tilbage hurtigt, hvilket gjorde disaster recovery fra en nagende baggrundsbekymring til noget med definerede trin. For en ung virksomhed betød det lige så meget psykologisk som teknisk: en fejl ville være en dårlig dag, man kommer sig over, ikke den slags, der ender produktet.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/da/portfolio/built-the-next-js-16-frontend-with-ssr-73/","url":"https://engineer.company/da/portfolio/built-the-next-js-16-frontend-with-ssr-73/","title":"Har bygget Next.js 16‑frontenden med SSR-, SSG- og CSR‑strategier og et server‑shell prefetch‑and‑hydrate‑mønster, der eliminerede N+1‑fetches.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e Det autentificerede dashboard skulle føles hurtigt og forblive oprigtigt interaktivt, og de to mål trækker mod hinanden, hvis man er naiv omkring det. Hent alt på klienten, og førsteindlæsningen sløver, og værre endnu får man N+1‑mønsteret, hvor hver komponent vågner og fyrer sin egen request af, så en enkelt side bliver til en kaskade af rundture.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eOpgave.\u003c/strong\u003e Hver del af appen skulle renderes på den måde, der faktisk passede til den, uden at opgive client‑side‑interaktiviteten, hvor den betød noget.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eHandling.\u003c/strong\u003e Next.js 16‑frontenden bruger den rette tilstand pr. flade i stedet for ét fladt valg. Marketing- og offentlige sider genereres statisk — de ændrer sig ikke pr. bruger, så der er ingen grund til at rendere dem ved hver request. Autentificerede sider server‑renderes, med et server‑shell prefetch‑and‑hydrate‑mønster — createPrefetchedServerPage — der henter sidens data på serveren og overlader dem til klienten allerede udfyldt, så komponenterne kommer op med deres data i stedet for hver at gå af sted for at spørge efter dem. De oprigtigt interaktive dele forbliver client‑renderede. Og en cache‑invalideringsstrategi er dokumenteret pr. forespørgsel, så data forbliver friske, uden at appen re‑fetcher ting, den allerede har.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResultat.\u003c/strong\u003e Sider indlæses hurtigt og forbliver fuldt interaktive, og N+1‑stormen på dashboardet forsvandt bare, fordi server‑shellen bringer det, siden har brug for, tilbage i én omgang. Frontenden endte med den oplevede hastighed af server‑rendering og responsiviteten fra en client‑app i stedet for at skulle vælge en af dem.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/da/portfolio/delivered-full-progressive-web-app-support-installable-and-74/","url":"https://engineer.company/da/portfolio/delivered-full-progressive-web-app-support-installable-and-74/","title":"Har leveret fuld Progressive Web App‑understøttelse — installerbar og offline‑dygtig — med Workbox runtime‑caching via next‑pwa.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e En stor del af NextMariners brugere er til søs. Søfarende og feltpersonale, på telefoner, ofte offline eller hængende på en dårlig forbindelse — ikke folk, der sidder ved et skrivebord på pålidelig kontor‑wifi. At bygge, som om alle havde et hurtigt, konstant netværk, ville stille og roligt have udelukket en stor del af det faktiske publikum.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eOpgave.\u003c/strong\u003e Appen skulle være installerbar som en native app og stadig brugbar, når netværket falder ud.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eHandling.\u003c/strong\u003e Den er leveret som en fuld Progressive Web App. Den installeres på hjemmeskærmen med ordentlige ikoner i de forskellige størrelser, en splash‑skærm og temafarver, så den ser ud og starter som en app frem for et bogmærke. Service workeren er sat op gennem next‑pwa‑pluginet, og Workbox runtime‑caching bruger CacheFirst til de ting, der ikke ændrer sig pr. request — skrifttyper, billeder, lyd, video, CDN‑aktiver — sammen med fornuftige HTTP cache‑control‑headere. Fordi service workers kun rigtig opfører sig over HTTPS, validerede HTTPS‑baseret test offline- og installationsadfærden på rigtige enheder i stedet for at håbe, det virkede.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResultat.\u003c/strong\u003e Brugere kan installere appen og blive ved med at bruge den offline, og genindlæsninger kommer hurtigt tilbage fra cache i stedet for over ledningen. Platformen opfører sig som en native app på det hardware, dens brugere faktisk bærer, hvilket for det her publikum ikke er en luksus — det er forskellen på, om appen er brugbar til søs eller ej.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/da/portfolio/designed-an-ios-26-liquid-glass-design-system-75/","url":"https://engineer.company/da/portfolio/designed-an-ios-26-liquid-glass-design-system-75/","title":"Har designet et iOS 26 'Liquid Glass'-designsystem og et kanonisk komponentbibliotek håndhævet af lint‑regler for at forhindre UI‑divergens.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e Et UI uden et fælles visuelt sprog og et fast sæt komponenter driver, og det driver hurtigt. Hver ny skærm genopfinder sine egne knapper og badges og kort, hver en lille smule anderledes, og de små inkonsistenser hober sig op, indtil produktet ser usammenhængende ud, og hver ændring betyder at røre fem specialbyggede versioner af den samme ting.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eOpgave.\u003c/strong\u003e Designsystemet skulle være sammenhængende nok til at se bevidst ud, og håndhævbart nok til, at det ikke eroderede i det øjeblik, teamet havde travlt.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eHandling.\u003c/strong\u003e Det visuelle sprog og komponentsystemet blev designet som én ting. Sproget er et iOS 26 \u0026ldquo;Liquid Glass\u0026rdquo;-look — gennemsigtige paneler med backdrop‑blur, lagdelte skygger, en smule refraktion, spring‑animationer — bygget af Tailwind‑utilities. Ovenpå det sidder et kanonisk sæt komponenter, hver skærm er ment til at sammensætte af: Card, Label, Button, GlassIconButton, DirectoryGrid og resten. Det, der får det til at sidde fast, er lintingen: regler, der afviser et hjemmelavet badge eller chip og peger dig på den kanoniske komponent i stedet, så systemet holdes oppe af værktøjer frem for af, at den, der reviewer den dag, husker at bekymre sig. Og dokumentationen er parret med konkrete fejl‑til‑løsning‑noter, så vejledningen er \u0026ldquo;her er den forkerte måde og den rigtige\u0026rdquo;, ikke et abstrakt princip.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResultat.\u003c/strong\u003e UI\u0026rsquo;et forbliver konsistent og on‑brand, og de engangskomponenter, der ellers ville sprede sig, fanges, før de gør. Visuel konsistens holdt op med at være et spørgsmål om alles disciplin og blev til noget, værktøjerne holder linjen på, hvilket er den eneste version af det, der overlever en deadline.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/da/portfolio/designed-the-product-s-ui-and-ux-end-76/","url":"https://engineer.company/da/portfolio/designed-the-product-s-ui-and-ux-end-76/","title":"Har designet produktets UI og UX fra ende til anden — directory‑grids, dobbelte kort/tabel‑visninger, live‑kravvalidatorer og breadcrumb‑navigation.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e NextMariner stiller en masse forskellige entiteter foran folk — professionelle, virksomheder, skibe, jobs, anmeldelser — og grænsefladen skulle være to ting, der slås med hinanden: flot og oprigtigt brugbar. Tæt nok til at vise rigtige maritime data, men ikke så tæt, at den bliver til en mur, man preller af på.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eOpgave.\u003c/strong\u003e Produktets UI og UX blev ejet fra ende til anden — layoutene, interaktionsmønstrene og det mindre, som hvordan nogen bliver ført gennem en formular uden at føle sig hakket på.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eHandling.\u003c/strong\u003e Et par beslutninger gjorde det meste af arbejdet. Directory‑grids har en kort/tabel‑toggle, så man kan browse visuelt eller scanne en tæt tabel, og appen husker, hvilken man valgte. Formularer bruger live‑kravvalidatorer, der sidder over inputtet og viser hver regel i grønt, når den er opfyldt, og ravgult, når den ikke er, så man bliver vejledt, mens man skriver, i stedet for hakket på, efter man har sendt. Navigationen er konsistente breadcrumbs og to‑kolonne‑entitetslayouts, så sider føles som det samme produkt frem for et sæt urelaterede skærme. Og fejlfilosofien er vejledning frem for fejl — ingen røde mure, redirects i stedet for blindgyder, appen prøver at holde dig i bevægelse frem for at stoppe dig.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResultat.\u003c/strong\u003e Det, der kom ud, er en poleret, konsistent oplevelse, der gør tætte maritime data overskuelige og styrer folk gennem de komplicerede dele. Den fremstår gennemtænkt og troværdig, hvilket ikke er kosmetisk på en platform, folk bruger til deres faktiske karriere — hvis den så sjusket ud, ville de stole mindre på dataene, og de ville have ret i det.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/da/portfolio/hardened-the-application-with-nonce-based-csp-hsts-77/","url":"https://engineer.company/da/portfolio/hardened-the-application-with-nonce-based-csp-hsts-77/","title":"Har hærdet applikationen med nonce‑baseret CSP, HSTS, SameSite‑cookies, least‑privilege‑databaseroller og server‑side‑genkontrol af rettigheder.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e NextMariner rummer professionelle og organisatoriske data, den slags folk forventer bliver håndteret ordentligt, så en enkelt forsvarslinje var aldrig nok. Arbejdsantagelsen må være, at klienten er fjendtlig — at alt, hvad browseren håndhæver, kan slås fra af den, der holder browseren — og sikkerheden må holde alligevel.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eOpgave.\u003c/strong\u003e Platformen skulle hærdes på hvert lag — frontend, API, database — så sikkerhed blev håndhævet af serveren uafhængigt af, hvad grænsefladen nu tilfældigvis tillod.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eHandling.\u003c/strong\u003e I frontenden sætter Next.js\u0026rsquo; proxy‑middleware — proxy.ts — en Content‑Security‑Policy med en per‑request‑nonce og strict‑dynamic, plus HSTS og SameSite‑cookies, så browseren er låst ned om, hvad den vil køre og sende. På API\u0026rsquo;et er der rate limiting, CORS, request‑størrelsesgrænser, input‑validering, før noget rører databasen, og logning af de sikkerhedsrelevante hændelser. I databasen logger API\u0026rsquo;et ind som en least‑privilege‑rolle, der kun kan EXECUTE app‑funktionerne, funktionerne kører SECURITY DEFINER, og alt er parametriseret. Og rettighederne — tier, rolle, organisation, skibs‑scoping — genkontrolleres på serveren ved hver request, hvor frontend‑gates kun behandles som UX. Gates afgør, hvad du ser; serveren afgør, hvad du må.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResultat.\u003c/strong\u003e Sikkerhed afhænger ikke af, at UI\u0026rsquo;et opfører sig. Beskyttelserne er lagdelte, så det at komme forbi én ikke får dig forbi resten, og det hele er bygget på antagelsen om, at klienten ikke kan stoles på — hvilket er den rigtige antagelse for data, folk overlader i fortrolighed.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/da/portfolio/established-an-english-danish-internationalization-system-with-linter-78/","url":"https://engineer.company/da/portfolio/established-an-english-danish-internationalization-system-with-linter-78/","title":"Har etableret et engelsk/dansk internationaliseringssystem med linter‑håndhævet ordforråd og et budget på 400 linjer pr. namespace.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e NextMariner kører på engelsk og dansk, og oversættelsessystemer har det med at vokse ud i et rod. Filerne vokser uden grænse, nøgler lækker — til stede i ét sprog, manglende i det andet — og de sprogspecifikke konventioner anvendes ujævnt, så ét sprog ender med at læse, som om det var oversat af et udvalg, der ikke talte sammen. For et professionelt produkt er det ikke en lille skønhedsfejl; det læses som sjusk.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eOpgave.\u003c/strong\u003e Internationaliseringssystemet skulle skalere — holde begge sprog konsistente og korrekte og filerne til noget, et menneske stadig kunne vedligeholde et år inde.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eHandling.\u003c/strong\u003e Det er bygget på next‑intl med regler, som værktøjerne faktisk håndhæver. Den danske side har et låst ordforråd og en låst stil — literal æøå, det uformelle \u0026ldquo;du\u0026rdquo;, de rigtige imperative accenter, og semantiske mappinger for sammensatte ord, så de oversættes efter betydning frem for ord‑for‑ord — og en linter holder den til det. Der er et hårdt budget på 400 linjer pr. namespace, med en split‑and‑merge‑tilgang, så et stort område deles i nestede filer, der merges rent tilbage, i stedet for at én fil vokser i det uendelige. Et linter‑tjek sammenligner nøgler på tværs af sprog, så intet lækker eller mangler. Og lagrede overrides merges katalogdrevet frem for med skrøbelige top‑niveau‑fallbacks — den samme deep‑merge‑idé, der blev brugt til præferencer.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResultat.\u003c/strong\u003e Begge sprog forbliver korrekte og konsistente, og filerne forbliver vedligeholdelige, efterhånden som antallet af strenge klatrer. Sprogkvalitet blev til noget, værktøjerne garanterer ved hver commit, frem for noget, der stille og roligt forringes, hver gang nogen tilføjer en streng i en fart.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/da/portfolio/set-a-zero-warnings-quality-bar-across-six-79/","url":"https://engineer.company/da/portfolio/set-a-zero-warnings-quality-bar-across-six-79/","title":"Har sat en zero‑warnings‑kvalitetsstandard på tværs af seks sprog — Go, TypeScript, SQL, Python, Shell og Markdown — håndhævet af pre‑commit‑hooks.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e Advarsler, der hober sig op, er stille og roligt ætsende. Hver diagnostik, man ignorerer, sænker barren en smule, og når først buildet spytter fyrre af dem ud, læser ingen nogen af dem, og et reelt problem sidder i den liste i fuldt dagslys, fordi \u0026ldquo;advarsler\u0026rdquo; er blevet til baggrundsstøj. I et polyglot‑kodebase er der så mange flere kilder til støj til at lade det ske.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eOpgave.\u003c/strong\u003e Repoet skulle have én kompromisløs kvalitetsstandard på tværs af hvert sprog, så ting blev rettet i stedet for at hobe sig op.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eHandling.\u003c/strong\u003e En zero‑warnings‑politik gik ind, med værktøjerne som det, der håndhæver den, for en politik, der bygger på alles årvågenhed, taber til den første travle uge. Hver linter‑diagnostik er en fejl — der er intet \u0026ldquo;warn\u0026rdquo;-niveau at gemme sig i — og det er det samme på tværs af hele stakken: Go med golangci‑lint, TypeScript med ESLint, SQL med SQLFluff, Python med Ruff, shell med ShellCheck, Markdown med markdownlint. Inline‑suppressions er forbudt, så man kan ikke papre hen over en diagnostik; man er nødt til faktisk at rette tingen. Pre‑commit- og pre‑push‑hooks kører linterne og testene, så en commit, der ville introducere et problem, slet ikke bliver lavet i første omgang. Der er endda grænser for funktions- og fillængde for at holde moduler fra at brede sig ud over det punkt, hvor de er læsbare.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResultat.\u003c/strong\u003e Problemer bliver rettet ved kilden i stedet for udskudt til en backlog, ingen rydder, og kodebasen forbliver ren som standard frem for ved periodiske heltemodige indsatser. Standarden er identisk, uanset hvilket sprog man er i, og det er værktøjerne, der holder den — ikke nogens viljestyrke — hvilket er derfor, den faktisk holder.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/da/portfolio/architected-and-implemented-the-platform-end-to-end-80/","url":"https://engineer.company/da/portfolio/architected-and-implemented-the-platform-end-to-end-80/","title":"Har arkitekteret og implementeret platformen fra ende til anden — backend, database, frontend, designsystem, infrastruktur og sikkerhed — og etableret det tekniske fundament og engineering‑standarderne.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e NextMariner satte sig for at bygge en hel maritim platform — professionelt netværk, virksomhedsanmeldelser, uddannelsessponsorater — fra bunden. Og fra bunden betød, at alt skulle findes på én gang: datamodellen, API\u0026rsquo;et, weboplevelsen, designsproget, cloud‑infrastrukturen, sikkerheden. Der var ingen eksisterende systemer at læne sig op ad, og en ung virksomhed i hurtig bevægelse, hvilket er spændende og en masse reb at hænge sig selv i, i lige høj grad.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eOpgave.\u003c/strong\u003e Platformens arkitektur og implementeringen blev ejet fra ende til anden. Jobbet var ikke bare at få det til at virke — det var at omsætte en produktvision til et sammenhængende, produktionsklart system, træffe de tekniske valg på tværs af hvert lag og sætte de engineering‑standarder, kodebasen skulle vokse indeni, frem for at stable genveje op, der skulle betales af på senere.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eHandling.\u003c/strong\u003e Hele stakken blev designet og bygget, så lagene passede sammen frem for hver at være lokalt smarte. Dataene bor i PostgreSQL med function‑first forretningslogik, UUID v7‑nøgler og normaliserede maritime skemaer. Go‑API\u0026rsquo;et — Huma oven på Fiber — sidder ovenpå som en tynd, valideret og sikker adapter over de funktioner og rummer ingen forretningslogik selv. Frontenden er en Next.js 16 PWA, der bruger SSR, SSG og CSR, hver hvor de passer, med et server‑shell prefetch‑and‑hydrate‑mønster, og den er klædt i et iOS 26 \u0026ldquo;Liquid Glass\u0026rdquo;-designsystem understøttet af et kanonisk, lint‑håndhævet komponentsæt. Under det hele er Azure‑infrastrukturen defineret i Bicep, sendt gennem CI/CD, med sikkerhed lagdelt fra nonce‑CSP\u0026rsquo;en ned til least‑privilege‑databaseroller og server‑side‑rettighedstjek. Og kvalitetsstandarden blev sat — en zero‑warnings‑politik på tværs af seks sprog, håndhævet af pre‑commit‑hooks — så standarden holdt fra den første commit frem for at være noget at love at rydde op i senere.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResultat.\u003c/strong\u003e NextMariner kom ud af det med en komplet, produktionsklar platform — en ren, lagdelt arkitektur med konsistente standarder hele vejen igennem. Fordi lagene var designet til at passe sammen frem for boltet sammen, er det et fundament, der skalerer med produktet og forbliver vedligeholdeligt, efterhånden som teamet og funktionaliteten vokser, i stedet for den slags første version, man ender med at måtte smide væk.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/da/portfolio/delivered-analysis-and-regular-progress-reports-to-the-81/","url":"https://engineer.company/da/portfolio/delivered-analysis-and-regular-progress-reports-to-the-81/","title":"Har leveret analyser og løbende statusrapporter til CEO'en og omsat engineering‑metrikker og leveringsstatus til beslutninger.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e Efterhånden som platformen kom sammen, skulle dens fremdrift og tilstand være synlig for ledelsen i termer, de faktisk kunne gøre noget med. Rå engineering‑signaler — build‑status, leveringstempo, incidents — betyder ikke meget i sig selv for en, der træffer produkt- og investeringsvalg; de er i den forkerte højde. Nogen måtte oversætte.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eOpgave.\u003c/strong\u003e Den oversættelse var jobbet: at tage engineering‑virkeligheden — hvor leveringen stod, hvad systemmetrikkerne sagde — og rapportere den til CEO\u0026rsquo;en klart og regelmæssigt, så beslutninger hvilede på fakta i stedet for gætværk.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eHandling.\u003c/strong\u003e En fast rapporteringsrytme gik ind frem for at rapportere, når der blev spurgt, hvilket altid er en anelse for sent. Leveringsfremdriften, scope, risiciene og systemtilstanden blev fulgt og omsat til klare, beslutningsorienterede opdateringer — hvad der var på sporet, hvad der var i risiko, og hvad en given prioritet faktisk ville koste i afvejninger. Det, der skulle undgås, var at aflevere rå tal og overlade fortolkningen til nogen uden konteksten; hver rapport kom med konkrete anbefalinger, og hvor det hjalp, blev fortællingen understøttet af de underliggende analyser, så ledelsen kunne gå i dybden, hvis de ville, frem for at skulle tage det på tro.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResultat.\u003c/strong\u003e Ledelsen endte med et klart, ærligt og aktuelt billede af engineering og kunne styre produktprioriteter og investeringer med en vis tillid i stedet for at flyve i blinde. Rapportering holdt op med at være et statusritual, ingen læser, og blev til noget, beslutninger faktisk blev truffet ud fra — hvilket holdt det tekniske arbejde og forretningsretningen pegende samme vej.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/da/portfolio/provided-round-the-clock-24-7-infrastructure-support-82/","url":"https://engineer.company/da/portfolio/provided-round-the-clock-24-7-infrastructure-support-82/","title":"Har leveret døgnbemandet 24/7‑infrastruktursupport til en IPTV/OTT‑streamingplatform og administreret ca. 1.000 servere samt kundeejede systemer for globale kunder i Kina, USA og Tyskland.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e Det her var en IPTV/OTT‑streamingplatform med kunder spredt over Kina, USA og Tyskland, hvilket betød, at der ikke var nogen stille time at lave vedligeholdelse i — nogen, et eller andet sted, kiggede altid med. Nedetid på sådan en platform er ikke en abstrakt måltal; det er nogens fjernsyn, der bare stopper, og de er ligeglade med hvorfor.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eOpgave.\u003c/strong\u003e At holde platformens infrastruktur tilgængelig døgnet rundt var jobbet — reelt døgnet rundt, ikke \u0026ldquo;kontortid plus en tilkaldevagt, ingen svarer på.\u0026rdquo;\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eHandling.\u003c/strong\u003e 24/7‑support kørte for omkring tusind servere, plus et pænt antal kundeejede systemer oveni — administreret, overvåget, holdt sikret og konfigureret på tværs af hele streaming‑estatet. Fordi kunderne sad i tre vidt forskellige tidszoner, fandtes \u0026ldquo;efter arbejdstid\u0026rdquo; ikke rigtig; et problem klokken 3 om natten lokalt var primetime for nogen andre, så det blev behandlet som primetime. En stor del af arbejdet var at bemærke noget, der drev af, før det blev til et nedbrud, for på en live streamingplatform får man ikke lov at rette ting stille bagefter.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResultat.\u003c/strong\u003e Platformen forblev kontinuerligt tilgængelig for et globalt publikum, med problemer fanget og håndteret på hvilken time end de dukkede op, før de nåede en seers skærm. På en 24/7‑tjeneste er det hele jobbet — succes ser ud som ingenting, der sker, hvilket er præcis, hvad seerne ville have.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/da/portfolio/ensured-uninterrupted-delivery-of-iptv-streaming-signals-between-83/","url":"https://engineer.company/da/portfolio/ensured-uninterrupted-delivery-of-iptv-streaming-signals-between-83/","title":"Har sikret uafbrudt levering af IPTV‑streamingsignaler mellem leverandører og kunder og overvåget og vedligeholdt streamingnetværket og IP‑telefonien døgnet rundt.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e IPTV lever eller dør på, at signalet kommer igennem. Streamsene flyder fra leverandører, gennem platformen, til kunderne, og ethvert brud hvor som helst i den kæde er en sort skærm for nogen. IP‑telefonien sad ved siden af, med det samme krav: den skulle bare virke.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eOpgave.\u003c/strong\u003e At garantere, at signalleveringen og telefonien forblev uafbrudt, var jobbet.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eHandling.\u003c/strong\u003e Streamingnetværket og IP‑telefonien blev overvåget, fejlfundet og vedligeholdt døgnet rundt. Pointen med at holde konstant øje er, at streamingproblemer melder sig som forringelse, før de bliver til et decideret drop — en stream, der begynder at hakke, et link, der bliver ustabilt — og hvis man er opmærksom, kan man fange det ved hakket i stedet for ved den sorte skærm. Så en stor del af det var at være foran signalet frem for at reagere på klager over det.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResultat.\u003c/strong\u003e Streamsene og opkaldene forblev pålidelige på tværs af platformen, med problemer opdaget og rettet, før de blev til en tjeneste, nogen bemærkede faldt ud. At holde et signal flydende mellem leverandører og slutkunder uden et synligt hul er stille, konstant arbejde, og stille er, hvad det bør være.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/da/portfolio/developed-and-maintained-django-web-applications-for-the-84/","url":"https://engineer.company/da/portfolio/developed-and-maintained-django-web-applications-for-the-84/","title":"Har udviklet og vedligeholdt Django‑webapplikationer til IPTV‑platformen med nye funktioner og forbedret performance og stabilitet.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e IPTV‑platformen havde webapplikationer bygget på Django omkring sig — de dele, folk faktisk klikkede på — og de skulle blive ved med at bevæge sig fremad: nye funktioner, og den performance og stabilitet, en platform, der kører døgnet rundt, kræver.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eOpgave.\u003c/strong\u003e At holde de applikationer funktionsrige, hurtige og stabile var opgaven.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eHandling.\u003c/strong\u003e Django‑webapplikationerne blev udviklet og vedligeholdt — byggede nye funktioner, rettede fejlene og pressede på performance og stabilitet, arbejdet på tværs af teamet frem for i et hjørne. På noget, der betjener kunder kontinuerligt, er stabilitetssiden ikke en luksus ved siden af funktionerne; det er den begrænsning, funktionerne må respektere. En prangende funktion, der får tingen til at vakle, er ikke meget værd, når tingen ikke har råd til at vakle.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResultat.\u003c/strong\u003e Applikationerne blev ved med at få flere funktioner og forblev samtidig pålidelige for både de interne teams og kunderne. At tilføje til noget uden at destabilisere det er den balance, der betød noget her, og det er det, arbejdet holdt sig til.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/da/portfolio/planned-and-implemented-new-infrastructure-functionality-for-internal-85/","url":"https://engineer.company/da/portfolio/planned-and-implemented-new-infrastructure-functionality-for-internal-85/","title":"Har planlagt og implementeret ny infrastrukturfunktionalitet til interne og eksterne systemer og bygget løsninger, der stadig kører år efter med minimale ændringer.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e Efterhånden som organisationen voksede, blev dens interne og eksterne systemer ved med at have brug for nye funktioner skruet på. Den nemme måde at gøre det på er, hvad end der er hurtigst i dag; problemet med den nemme måde er, at man er tilbage og retter det om et halvt år.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eOpgave.\u003c/strong\u003e At planlægge og bygge infrastrukturfunktionalitet, der faktisk ville holde, var opgaven — ikke bare virke nu, men blive ved med at virke.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eHandling.\u003c/strong\u003e Ny infrastrukturfunktionalitet blev planlagt og implementeret på tværs af de interne og eksterne systemer, designet til at være holdbar — den slags, man bygger én gang, ordentligt, så den bliver ved med at køre i årevis med minimal berøring frem for at kræve konstant opmærksomhed. Det er et bevidst valg hver gang: at bruge en smule mere tanke i starten, så man ikke skriver sig op til at passe på den for evigt.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResultat.\u003c/strong\u003e Systemerne forblev funktionelle og effektive længe efter, de blev bygget, og kørte i årevis med næsten ingen ændringer. Den lang levetid er det egentlige mål for infrastrukturarbejde — enhver kan lave noget, der virker i dag; at lave noget, der stadig stille og roligt virker år senere, er det sværere og mere nyttige.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/da/portfolio/as-one-of-the-first-hires-designed-and-86/","url":"https://engineer.company/da/portfolio/as-one-of-the-first-hires-designed-and-86/","title":"Har som en af de første medarbejdere designet og bygget hele kerneinfrastrukturen og de understøttende processer fra bunden for en grøn‑energi‑SaaS‑startup og lagt fundamentet for hurtig vækst.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e Det her var en grøn‑energi‑SaaS‑startup med en lovende idé og reelt ingen teknisk fundament under sig endnu. At komme ind som en af de første medarbejdere betød det stadie, hvor der ikke er noget at vedligeholde, fordi der ikke findes noget — man bygger den grund, alle andre skal stå på.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eOpgave.\u003c/strong\u003e At bygge kerneinfrastrukturen og processerne omkring den, fra bunden, var jobbet.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eHandling.\u003c/strong\u003e Hele kerneinfrastrukturen og dens understøttende processer blev designet og bygget — serverne, netværkene, dataflowet, sikkerheden, driftssiden. At gøre det i en startup betyder at træffe beslutninger, der er svære at omgøre senere, så målet var ikke bare \u0026ldquo;få noget til at køre\u0026rdquo;, det var at lægge et fundament, der kunne bære vægten af hurtig vækst uden at skulle rives ud i det øjeblik, virksomheden blev større. Tidlige infrastrukturvalg bliver enten det, der lader dig skalere, eller det, du bruger et år på at gøre om; sigtet var klart den første slags.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResultat.\u003c/strong\u003e Startuppen kom ud med et solidt teknisk fundament, og det er det, der lod forretningen vokse hurtigt bagefter. At være den, der bygger den base fra ingenting, er en særlig slags ansvar — gør du det rigtigt, bemærker ingen det, gør du det forkert, bemærker alle det — og denne holdt.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/da/portfolio/maintained-and-enhanced-the-legacy-hugo-static-site-87/","url":"https://engineer.company/da/portfolio/maintained-and-enhanced-the-legacy-hugo-static-site-87/","title":"Har vedligeholdt og forbedret det ældre Hugo‑baserede statiske website og bidraget med UI/UX‑forbedringer til det primære asset management‑produkt.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e Der var et ældre website bygget på Hugo — en statisk site‑generator — der kørte ved siden af virksomhedens hovedprodukt, et asset management‑system. Websitet var den gamle, etablerede ting; produktet var, hvor den reelle værdi sad.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eOpgave.\u003c/strong\u003e At holde websitet sundt og samtidig forbedre produktets oplevelse var opgaven.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eHandling.\u003c/strong\u003e Det statiske Hugo‑site blev vedligeholdt og forbedret — holdt opdateret og fungerende — mens UI/UX‑forbedringer og feedback samtidig fodredes ind i det primære asset management‑produkt. At dele opmærksomheden mellem et ældre site og flagskibsproduktet handler mest om ikke at lade den gamle ting rådne, mens man er fokuseret på den nye; begge repræsenterer virksomheden over for nogen, så begge skulle holdes anstændige.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResultat.\u003c/strong\u003e Websitet forblev opdateret i stedet for stille at ældes, og hovedproduktets brugervenlighed blev bedre gennem stabil, velinformeret forfinelse — den slags, der kommer af faktisk at bruge og tænke over tingen frem for at redesigne den i ét stort greb.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/da/portfolio/designed-a-time-management-and-reporting-system-that-88/","url":"https://engineer.company/da/portfolio/designed-a-time-management-and-reporting-system-that-88/","title":"Har designet et tids- og rapporteringssystem, der forblev i produktion i årevis uden væsentlige ændringer.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e Teamet havde ikke en pålidelig måde at styre tid og rapportere fremdrift på. Hvilket som regel betyder, at det sker i en spredning af regneark og hukommelse, og at rapporteringen bliver en kamp ved slutningen af hver periode frem for noget, der bare falder ud af, hvordan folk arbejder.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eOpgave.\u003c/strong\u003e At bygge et system til begge dele, der faktisk ville holde, var opgaven.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eHandling.\u003c/strong\u003e Et tids- og rapporteringssystem blev designet op omkring den måde, teamet reelt arbejdede på, frem for at påtvinge en hyldevareproces, de ville ruter uden om. Det er hele kunsten med interne værktøjer — hvis det passer til det virkelige workflow, bruger folk det; hvis det slås med workflowet, forlader de det stille og roligt, og man er tilbage ved regneark. Så det blev bygget til at matche virkeligheden frem for et ideal.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResultat.\u003c/strong\u003e Det forblev i produktion i årevis uden nogen væsentlig ændring. Det er den kompliment, man vil have for et internt værktøj — ikke at det var imponerende, men at det bare blev ved med at virke, og ingen nogensinde behøvede at udskifte det. Noget, der overlever år med daglig brug urørt, var tydeligvis bygget til at passe.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/da/portfolio/automated-team-collaboration-password-management-task-and-time-89/","url":"https://engineer.company/da/portfolio/automated-team-collaboration-password-management-task-and-time-89/","title":"Har automatiseret teamsamarbejde, adgangskodehåndtering, opgave- og tidsstyring og bygget et semi‑automatisk projektvisningssystem, hvilket øgede teamets produktivitet.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e En stor del af teamets driftsarbejde — at koordinere, håndtere adgangskoder, tracke opgaver og tid — blev lavet i hånden, og manuel koordinering er en stille skat: det er aldrig det, man bemærker, men det æder støt timer, der kunne gå et bedre sted hen.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eOpgave.\u003c/strong\u003e At automatisere det gentagne driftsarbejde var målet.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eHandling.\u003c/strong\u003e De dele, der egnede sig til det, blev automatiseret — teamsamarbejde, adgangskodehåndtering, opgavestyring, tidsstyring — med et semi‑automatisk projektvisningssystem oveni. Idéen på tværs af det hele var at tage rutinekoordineringen af folks bord, så den kørte af sig selv, og lade dem bruge den genvundne opmærksomhed på arbejde, der faktisk krævede et menneske. Visningssystemet var det samme instinkt anvendt på noget mere synligt: at gøre det at præsentere arbejdet mest muligt automatisk frem for en manuel pligt hver gang.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResultat.\u003c/strong\u003e Driftseffektiviteten steg, og teamet blev mere produktivt, fordi den rutinekoordinering, der før krævede konstant menneskelig opmærksomhed, nu i vid udstrækning kørte af sig selv. Den tid, der lækkede ud i pseudoarbejde, gik tilbage i det faktiske arbejde.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/da/portfolio/integrated-a-company-wide-password-management-system-strengthening-90/","url":"https://engineer.company/da/portfolio/integrated-a-company-wide-password-management-system-strengthening-90/","title":"Har integreret et virksomhedsdækkende adgangskodehåndteringssystem, der styrkede sikkerheden og strømlinede adgangskontrollen.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e Adgangsoplysninger blev håndteret inkonsistent — forskellige folk lagrede og delte dem på forskellige, ad hoc‑måder — og den inkonsistens er i sig selv sikkerhedsrisikoen. Det er sjældent et dramatisk brud; det er en adgangskode i en chatbesked, et delt login, ingen roterer, den langsomme ophobning af små eksponeringer.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eOpgave.\u003c/strong\u003e At centralisere oplysningerne og gøre dem sikre var opgaven.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eHandling.\u003c/strong\u003e Et virksomhedsdækkende adgangskodehåndteringssystem gik ind, så der var én konsistent, sikker måde, oplysninger blev lagret og delt på, i stedet for hver enkelts personlige vane. Værdien af virksomhedsdækkende er præcis, at det ikke er valgfrit pr. person — en adgangskodehåndtering, kun halvdelen af teamet bruger, hjælper knap nok, for risikoen bor i den halvdel, der ikke gjorde. Så pointen var at gøre den sikre måde til standardmåden, overalt.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResultat.\u003c/strong\u003e Sikkerheden blev bedre, og adgangskontrollen blev enklere og mere konsistent i hele organisationen. Når først oplysningerne alle bor ét administreret sted, holder et helt sæt små, kedelige eksponeringer bare op med at være mulige — hvilket er det meste af, hvad sikkerhed i den virkelige verden faktisk er.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/da/portfolio/drove-client-web-success-by-combining-custom-website-91/","url":"https://engineer.company/da/portfolio/drove-client-web-success-by-combining-custom-website-91/","title":"Har skabt succes for kunder på nettet ved at kombinere skræddersyet webudvikling og -design med SEO, indholdsstrategi og tekstforfatning.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e Kunder ville ikke egentlig have et website; de ville have det, et website er ment til at gøre for dem — at blive fundet, at trække kunder ind, faktisk at virke som en kanal. Et smukt site, ingen kan finde, er en fiasko, der ligner en succes.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eOpgave.\u003c/strong\u003e At kombinere opbygningen og vækstsiden i ét tilbud var opgaven, frem for at aflevere et site og ønske dem held og lykke.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eHandling.\u003c/strong\u003e De to halvdele blev sat sammen — skræddersyet webudvikling og -design på den ene side, SEO, indholdsstrategi og tekstforfatning på den anden — så en kunde fik noget, der både var velbygget og faktisk synligt. De bliver som regel behandlet som separate jobs, hvilket er, hvordan man ender med et smukt site, der rangerer ingen steder, eller et veloptimeret site, der er ubehageligt at bruge. At gøre begge dele betød, at sitet var designet fra starten til at blive fundet, ikke optimeret som en eftertanke.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResultat.\u003c/strong\u003e Kunderne endte med stærkere synlighed og mere engagement — deres sites virkede som ægte vækstkanaler frem for online brochurer. At bygge tingen og gøre den findbar i én omgang er det, der gjorde et website fra en omkostning til noget, der faktisk tjente sig ind.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/da/portfolio/performed-data-recovery-across-a-wide-range-of-92/","url":"https://engineer.company/da/portfolio/performed-data-recovery-across-a-wide-range-of-92/","title":"Har udført datagendannelse på tværs af en bred vifte af medier — SD‑kort, harddiske, SSD'er, RAID‑arrays, eksterne drev og Mac‑systemer.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e Folk dukkede op med lagring, der var gået i stykker eller var beskadiget, og data på den, de akut skulle have tilbage — og når først nogen bærer et dødt drev ind i en butik, er de som regel forbi bekymrede og inde i panikken. Billeder, forretningsfiler, den eneste kopi af noget, der betød noget.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eOpgave.\u003c/strong\u003e At gendanne deres data, på tværs af hvilke medier de end kom ind med, var jobbet.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eHandling.\u003c/strong\u003e Datagendannelse kørte på tværs af stort set enhver almindelig lagringstype — SD‑kort, roterende harddiske, SSD\u0026rsquo;er, RAID‑arrays, eksterne drev, Mac‑systemer. Hver af dem fejler og giver sine data fra sig forskelligt: en SSD er et andet problem end et pladedrev, et RAID‑array er et andet problem igen, og et Mac‑filsystem har sine egne særheder. Så arbejdet handlede lige så meget om at kende den rette tilgang til det specifikke medie, som det handlede om nogen enkelt teknik.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResultat.\u003c/strong\u003e Kunderne fik kritiske data tilbage fra enheder, de allerede havde afskrevet som tabt, på tværs af enhver almindelig slags lagring. Der er en specifik lettelse i nogens ansigt, når man rækker drevet tilbage med deres filer intakte — det var pointen med arbejdet, og det skete på tværs af hele viften af medier.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"},{"id":"https://engineer.company/da/portfolio/diagnosed-and-repaired-laptop-hardware-screens-hinges-keyboards-93/","url":"https://engineer.company/da/portfolio/diagnosed-and-repaired-laptop-hardware-screens-hinges-keyboards-93/","title":"Har diagnosticeret og repareret laptop‑hardware — skærme, hængsler, tastaturer, trackpads, bundkort og strømforsyninger — og løst softwareproblemer på tværs af Linux, Windows og Mac.","content_html":"\u003cp\u003e\u003cstrong\u003eSituation.\u003c/strong\u003e Laptops kom ind med hele viften af ting, der går galt med laptops — knuste skærme, ødelagte hængsler, døde tastaturer, svigtende trackpads, bundkortsfejl, strømproblemer — plus softwaresiden, på tværs af Linux, Windows og Mac. Kort sagt, hvad end der var galt med den, landede den på bænken.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eOpgave.\u003c/strong\u003e At diagnosticere og reparere dem pålideligt var jobbet — pålideligt som det afgørende ord, for en laptop‑reparation, der ikke holder, er bare et forsinket andet besøg.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eHandling.\u003c/strong\u003e Hardwaren blev repareret fra ende til anden — skærme, hængsler, tastaturer, trackpads, bundkort, strøm — hvilket på bundkortsniveau er oprigtigt fint, tæt arbejde, og softwareproblemerne løst på tværs af alle tre styresystemer. Diagnosen er som regel den egentlige færdighed: en laptop, der ikke vil tænde, kunne være opladeren, kortet eller batteriet, og reparationen er kun så god som gættet på, hvad der faktisk er i stykker. Så omhuen gik i at finde den rigtige fejl, før noget blev rørt.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResultat.\u003c/strong\u003e Maskinerne kom tilbage til deres ejere velfungerende og pålidelige, hardware og software begge ordnet. En reparation, der holder, er den eneste slags værd at lave, og at få diagnosen rigtig først er det, der fik disse til at holde.\u003c/p\u003e\n","date_published":"2026-07-30T21:33:07+02:00"}]}