Media & Publishing: zamki-szkocji.com

#zamki-szkocji.com, din guide til de magiske slottene i Skottland

Et kart er ofte det første folk tar i på en nettside om steder, og det er også det som ryker først når innholdet vokser. zamki-szkocji.com er en informasjonsportal om slott og borger i Skottland: historiske artikler, interaktivt kart, foto- og videogallerier og praktiske opplysninger for den som planlegger en tur. Portalen kom på nett i 2012, kjører på WordPress med Redis som objektcache og ligger på AWS-infrastruktur med CDN foran mediefilene. Utviklingen tok omtrent seks uker. Kunden leverte layout og plassering av elementer; min del var å gjøre den layouten om til en innholdsmodell, maler og integrasjoner som fortsatt bærer etter mange år med nye oppføringer.

#Kartet krever data, ikke tekst

Det interaktive kartet bruker Google Maps API sammen med egne endepunkter som leverer stedsdata i en form som passer til å tegne markører. Skillet er hele poenget. Dersom kartet hadde spurt etter hele innlegg, ville hver visning dratt med seg den fullstendige historiske teksten bare for å tegne en prikk og tre setninger i en boble. Et eget endepunkt returnerer kun det kartet faktisk tegner: svaret blir lite, det lar seg cache, og det endrer seg ikke hver gang noen retter en formulering i artikkelen.

Den andre grunnen handler om vedlikehold. All stedsinformasjon går gjennom ett sted, så regler som at et objekt uten koordinater ikke skal vises, eller at en ruin uten opplysninger om adkomst ikke hører hjemme på kartet, ligger i koden i stedet for i redaksjonens hukommelse. På en portal som vokser i ti år er det forskjellen mellom et kart som speiler databasen, og et kart noen må gå gjennom manuelt én gang i året.

Enhver ekstern karttjeneste kommer med samme bytte. Leverandøren gir fliser, geokoding og en oppførsel brukerne kjenner fra andre sider, og binder til gjengjeld prosjektet til andres kvoter og andres nøkkelpolitikk. I stedet for å late som om den kostnaden ikke finnes, holdes antall kall nede: kartet lastes først når det trengs, ikke på hver listeside, og svarene fra det egne endepunktet mellomlagres slik at rulling i en liste ikke skaper trafikk mot leverandøren.

#Hovedfunksjoner og tekniske løsninger

Selve grunnvalget ligger under kartet: et slott er en post med egne felter, ikke et blogginnlegg. Koordinater, adkomst, region, historisk periode, arkitektonisk stil, galleri, videomateriale og en tidslinje over hendelser knyttet til bygget. I WordPress betyr det en egen innholdstype med egne taksonomier.

Forskjellen viser seg først når mengden øker. Med tjue objekter holder vanlige stikkord, og ethvert alternativ ser ut som overarbeid. Med flere hundre er stikkord ikke lenger en klassifisering, men en haug nesten-synonymer. Noen oppføringer sier Highlands, noen sier nord, enkelte sier begge deler, og ingen kan lenger vise at en liste er komplett. En lukket taksonomi tvinger avgjørelsen fram i det øyeblikket oppføringen skrives, mens kilden fortsatt ligger framme.

Prisen er stivhet. Et fast vokabular må tenkes gjennom på forhånd, og å endre det senere er en datamigrering, ikke en tekstretting. Her var byttet enkelt, siden Skottlands geografi og inndelingen av forsvarsarkitektur ikke flytter seg fra år til år. For en portal om arrangementer eller tilbud, der vokabularet beveger seg med markedet, ville det samme valget vært feil.

Tidslinjen fortjener en egen merknad. Det frister å lime den inn i brødteksten som ferdig markup. Det ser riktig ut den første dagen og er ubrukelig alle andre steder. Lagret som datoer og hendelser kan den vises i flere oppsett, sorteres og rettes ett sted den dagen noen oppdager at to kilder daterer ombyggingen av en fløy ulikt.

Gallerier og mediebytte går gjennom AJAX, så bla mellom bilder laster ikke hele siden på nytt. Gevinsten er åpenbar, kostnaden mindre. Innhold som først finnes etter at et skript har kjørt, finnes ikke for alle besøkende: i verste fall ikke for en søkerobot, i enda verre fall ikke for en skjermleser. Adressen til et enkeltbilde og beskrivelsen av objektet må derfor ligge i et vanlig HTML-dokument. AJAX skal gjøre navigasjonen raskere, ikke være eneste vei inn.

Kommentarer og vurderinger lar besøkende legge igjen sin egen erfaring med et sted. Funksjonen er rask å slå på og dyr å holde i live, for ethvert åpent skjema på en side som er synlig i søk blir funnet av automatisert trafikk i løpet av uker. Lærdommen fra dette prosjektet er å moderere strengt først og slakke på det senere, framfor å rydde bort måneder med lenkespam under beskrivelsen av en middelalderborg.

#Utfordringer og implementerte programmeringsløsninger

Ytelse var den reelle begrensningen, og den kunne ikke løses ved å gjøre siden lettere. Bildene er innholdet. Å fjerne dem ville forbedret målingen og samtidig fjernet grunnen til at noen besøker siden.

Redis tar objektcachen. En WordPress-side settes sammen av mange små lesninger: innstillinger, metadata, taksonomirelasjoner. På en arkivvisning med titalls objekter og feltene deres vokser antallet slike lesninger raskere enn antallet synlige elementer skulle tilsi. Når resultatene ligger utenfor databasen, gjentar ikke neste forespørsel det samme arbeidet. Dette hjelper nettopp der en full sidecache ikke rekker: parametriserte visninger, kartendepunktet, enhver forespørsel fra en innlogget redaktør.

CDN tar mediene. Slottsfotografi er tungt, og publikum fordeler seg mellom Polen, De britiske øyer og hvor som helst noen planlegger ferie fra. Å levere filene fra ett sted betyr at halve publikum venter på en overføring tvers over Europa hver gang. Levering fra steder nær leseren tar i tillegg arbeid bort fra applikasjonsserveren som aldri hørte hjemme der.

Trafikken på en reiseside fordeler seg ikke jevnt, og det endrer hva som er verdt å optimalisere. Den stiger med sesongen og hopper etter omtale i presse eller deling i en stor interessegruppe. Å innstille etter månedsgjennomsnittet gir lite. Det som teller er timen da siden får mangedobbel last, og i den timen redder ikke raskere kode noe som helst. Det som redder situasjonen er at de fleste svarene aldri når fram til applikasjonen.

Cachetider ble satt bevisst, ikke arvet fra en standardverdi i en utvidelse. En slottsbeskrivelse kan ligge i cache i timevis, den endres noen ganger i året. En melding om midlertidig stengt kan ikke det, for det er akkurat den opplysningen noen åpner siden for kvelden før avreise. Å skille de to tilfellene er billigere enn å korte ned levetiden globalt, som ødelegger ytelsen overalt for å rette opp én visning.

Alt dette ble målt mot en kopi av produksjon, ikke mot en tom installasjon. En tom WordPress med et tema og to innlegg svarer alltid raskt, uansett hvordan spørringene er skrevet. Først en database med hele objektbestanden, metadataene, taksonomirelasjonene og kommentarhistorikken viser hvilken spørring som skanner halve tabellen og hvilken som bruker en indeks.

På søkesiden besto arbeidet av semantisk HTML5, ryddige metadata, lesbare adresser utledet av strukturen framfor av identifikatorer, og strukturerte data etter schema.org for slottsartiklene. Hensikten er avgrenset: å beskrive for en maskin det et menneske leser ut av oppsettet. Strukturerte data løfter ikke en svak tekst over en god. De hindrer at en god tekst blir oversett fordi en søkerobot ikke klarte å avgjøre hva slags side den så på. Jeg har ingen målinger av effekten som jeg kunne oppgitt med god samvittighet, så jeg oppgir ingen.

#Støtte og vedlikehold av nettstedet

Den løpende oppfølgingen omfatter oppdateringer av kjerne, tema og utvidelser, gjennomgang av logger, sikkerhetskopier og mindre funksjonelle og visuelle endringer. For et nettsted som har vært i drift siden 2012, er vedlikeholdet den største delen av historien, og det bør budsjetteres deretter i stedet for å behandles som en ettertanke.

Oppdateringer testes på en kopi. Et prosjekt med egen innholdstype, egne taksonomier og ekstern kartintegrasjon har flere steder der en endring i kjernen eller i en utvidelse endrer oppførsel uten å melde en feil: en spørring settes sammen annerledes, et filter en visning bygde på forsvinner, kartleverandøren pensjonerer en gammel autentiseringsmetode.

En sikkerhetskopi er en gjenopprettingsprosedyre, ikke en fil på en disk. En kopi ingen har gjenopprettet fra, er en hensiktserklæring. Verdi har den kopien noen allerede har satt opp en fungerende versjon av nettstedet fra, med en notis om hvor lang tid det tok.

#Oppsummering

zamki-szkocji.com holder stand på grunn av valg som ikke synes utenfra: slott modellert som poster framfor artikler, kartdata skilt ut i sitt eget endepunkt, objektcache holdt atskilt fra medielevering, og innhold som blir liggende i HTML-dokumentet også der AJAX gjør navigasjonen raskere.

Det som følger med videre til neste prosjekt er det tekniske laget og metoden: WordPress, Redis, AWS og CDN, strukturerte data, måling mot en kopi av produksjon. Det som ikke følger med er innholdsmodellen og integrasjonene til denne portalen, skrevet for ett datagrunnlag og én måte å lese på. En ny leveranse begynner med en gjennomgang av omfanget, og prisen kommer etter den gjennomgangen, ikke før.