Samma kodbas driver två sajter med olika namn, olika färger och olika ordval. Den ena arrangerar racingresor, den andra gruppresor. Under ytan är det samma program.
Det intressanta visade sig inte vara temalagret. Det var att jag gick in i en vägg som fick mig att bygga något helt annat.
Ett tema är mer än färger
Temavalet sker vid bygget: samma källkod kompileras två gånger med olika flagga, och resultatet läggs på två separata instanser. Temat styr tre saker.
Färgerna, vilket är det uppenbara och det minst viktiga.
Lexikonet, vilket är det som faktiskt betyder något. Samma lista heter startlista på den ena sajten och deltagare på den andra. Samma knapp säger ”nu rullar vi” respektive ”nu åker vi”. Samma funktion heter Race Control i det ena fallet och Reseledningen i det andra.
Det är inte kosmetika. En förening som ska på bussresa till Öland känner sig inte hemma i något som pratar om startlistor och Race Control, hur bra funktionerna än är. Och omvänt: den som ska köra Nordschleife vill inte ha ”reseledningen”. Ordvalet avgör om produkten känns gjord för dig eller om du använder någon annans verktyg.
Funktionsflaggor, som stänger av det som inte hör hemma. Fartvisning finns i racingversionen och är avstängd i resversionen — inte för att den inte fungerar, utan för att en buss inte behöver den, och att visa den vore att sända fel signal om vad produkten är.
Fällan med två instanser
En kodbas, två driftsatta kopior. Det låter oskyldigt och har en uppenbar följd som jag ändå gick på två gånger: en ny funktion som bara driftsätts på den ena sajten finns inte på den andra.
Första gången var en AI-funktion som låg kvar på gamla versionen i en vecka på den ena sajten. Andra gången var hela den digitala reseledningen — checklistor och uppdateringar om trafik och ändringar — som fungerade på racingsajten medan resesajten låg kvar utan den.
Regeln som växte fram: ingen sajtspecifik kod i en commit. Skiljer sig sajterna åt ska skillnaden ligga i temat, aldrig i logiken. Då kan exakt samma bygge gå till båda instanserna, och frågan ”är de i synk?” blir en jämförelse av två versionsnummer i stället för en genomläsning.
Och så det som verkligen var svårt
Både varianterna har ett live-läge: under resan syns deltagarnas position på en karta, så man ser om konvojen hänger ihop och vem som stannat för att tanka.
Det är en av de där funktionerna som är triviala att demonstrera och närmast omöjliga att få att fungera på riktigt.
En webbapp kan inte läsa position när skärmen är släckt. Både iOS och Android fryser sidans kod när telefonen låses. Det är inte en bugg, det är hela poängen med hur mobiler sparar batteri — och det innebär att positionsdelningen dör i samma sekund föraren stoppar telefonen i fickan.
Det finns ett API för att hålla skärmen vaken, och det används. Men då lyser skärmen hela resan och äter batteri, i en bil, ofta utan laddare. Lösningen blev ett mörkerläge: en nästan svart skärm med bara klocka och hastighet, snålt på en OLED-skärm, som håller sidan vaken utan att lysa upp kupén.
Till det kommer en tyst felkälla: när fliken väcks efter viloläge kan positionsbevakningen ha dött utan att säga något. Den ser aktiv ut och levererar aldrig mer. Fixen är att starta om den varje gång fliken blir synlig — man kan inte lita på att den överlevde.
Slutsatsen var obekväm: äkta spårning med låst telefon kräver en riktig app med bakgrundsrättigheter. Det är parkerat, medvetet, för det är ett helt annat åtagande än en webbsida.
Hålet i kartan
Den låsta skärmen var ändå ett problem man kan leva med. Den som kör bil kan lägga telefonen i en hållare.
Det verkliga hålet visade sig när resan inte gick på väg.
En gruppresa där deltagarna flyger har ett fönster på flera timmar där kartan helt enkelt är tom för dem. Från det att telefonen går i flygläge vid gaten till att den kopplar upp mot ett nät på destinationen finns ingen position att dela. Inte för att appen är dålig — utan för att det är regeln. Det finns ingen fix, ingen behörighet att be om, ingen bakgrundstjänst som hjälper.
Och det är precis den sträckan man vill se. Hela poängen med en reseledning är att veta var folk befinner sig, och den timme man verkligen undrar är den då de sitter i luften.
Vändningen: spåra farkosten, inte passageraren
När man stirrat på det tomma fältet några gånger vänder frågan sig själv. Jag försökte få personen att rapportera var hon var. Men personen sitter i något som redan sänder sin position — högt, tydligt och oavbrutet.
Varje trafikflygplan skickar ut identitet, höjd, fart och koordinater flera gånger i sekunden, okrypterat, till vem som helst som lyssnar. Ingen app, inget tillstånd, ingen batteridiskussion, inget flygläge som stänger av det.
Vet man flightnumret vet man alltså var deltagarna är — inte på metern, men fullt tillräckligt för en karta som ska svara på ”var är de nu, och när landar de?”.
Det kräver en mottagare, en antenn och en hel del lärdomar om radio. Så jag byggde en: ftrack.mer.nu. Den historien får ett eget inlägg, för där väntade en helt annan sorts fälla — och en obehaglig läxa om att lita på ett spec-blad.
Vad jag tar med mig
Ett varumärke är billigare än en produkt. Att göra en andra sajt av samma kod kostade ett temalager och en byggflagga. Att göra en andra produkt hade kostat allt. Skillnaden ligger i disciplinen att aldrig lägga sajtspecifik logik i koden.
Orden är en del av funktionen. Jag underskattade hur mycket lexikonet gör. Samma skärm med bytt vokabulär känns som två olika produkter för användarna — och det är i praktiken det de är.
Och den bästa idén kom ur en funktion som inte gick att bygga. Det tomma fältet i kartan när deltagarna flyger går inte att fylla med mer möda på telefonsidan — flygläget är inte ett hinder att kringgå, det är ett villkor. Först när jag slutade försöka övertala apparaten och frågade vad som redan sänder frivilligt fanns det ett svar. Det satt i luften ovanför huset.