Kunstige planter av høy kvalitet - sztuczne-rosliny.pl

#sztuczne-rosliny.pl, nettbutikk for kunstige planter av høy kvalitet

Bestillingene i denne butikken har to svært ulike former. Den ene er en enkelt monstera til en stue, valgt på telefonen om kvelden. Den andre er førti oliventrær i samme høyde til en hotellobby, med monteringsdato og krav om brannhemmende utførelse. Den samme produktsiden må bære begge situasjonene, og det betyr at den ikke kan være en plakat. Den må være et datablad.

Selskapet importerer og distribuerer kunstige planter, driver i tillegg grossistsalg og leverer grønne løsninger til kontorer, hoteller, restauranter, kjøpesentre og messestands, med montering og rådgivning på stedet. Hovedkontoret ligger i Warszawa, avdelingen i Białystok. Sortimentet omfatter trær, gress, blomster og potter, deriblant brannhemmende og UV-bestandige varianter samt grønne vegger (kilde: sztuczne-rosliny.pl).

Leveransen tok rundt seks uker. Teknisk står butikken på WordPress med en egen produktmodell, Redis som objektcache, HTML5, CSS3 og SASS i grensesnittet, AJAX i søket, fillagring i S3 med CDN foran og overvåking etter lansering. Layout og plassering av elementene kom fra kunden.

#Katalogen er daglig arbeid, ikke et leveransepunkt

En butikk med dette sortimentet er ikke ferdig på lanseringsdagen. Tilbudet endrer seg med hver leveranse, og den som forvalter katalogen sitter i administrasjonen hver dag. Krever det en utvikler å legge inn en plante, vil katalogen skille lag med virkeligheten i løpet av én sesong, uansett hvor godt den så ut ved overlevering.

Produktmodellen ligger derfor i egne innholdstyper og egendefinerte felt. Høyde, materiale, farge, pottetype, produsent og opplysningen om varianten er brannhemmende eller UV-bestandig er verdier i databasen og ikke setninger i en beskrivelse. Redaksjonen fyller ut et skjema i stedet for å skrive en tekst der rekkefølgen på opplysningene må huskes, og hver oppføring ser lik ut, fordi utseendet er malens oppgave og ikke oppgaven til den som taster inn.

Kategoriordenen er den andre avgjørelsen som ser organisatorisk ut og er teknisk. Planter kan sorteres etter art, høyde, bruksområde og innredningsstil samtidig, og det frister å lage et eget kategoritre av hver akse. Da henger det samme produktet fire steder, og redaksjonen vedlikeholder fire lister i stedet for én. I praksis bærer ett hierarki navigasjonen, mens de øvrige dimensjonene er attributter det filtreres på. Valget avgjør hvor mange adresser butikken sender ut i verden.

#Den engelske versjonen og spørsmålet om adresser

Butikken fører sortimentet også på engelsk, og det tvinger fram en avklaring før den første oversettelsen: skal hver språkversjon ha sin egen adresse, eller skal den samme adressen bytte innhold etter en innstilling. Bare det første alternativet er brukbart for søkemotorer, for en adresse som endrer innhold avhengig av en informasjonskapsel kan verken lenkes til, indekseres eller caches fornuftig.

Deretter må det avgjøres hvilke sider som i det hele tatt har en motpart. En produktside har det, en kategori har det, et filterresultat helst ikke, ellers vokser antallet adresser med hver kombinasjon i begge språk. Uten den grensen oppstår nøyaktig den tilstanden en katalog ikke tåler: mange adresser som viser det samme, og ingen av dem med tydelig forrang.

Datamodellen gjør denne delen enklere enn den pleier å være. Målbare felt er språknøytrale, så bare teksten skal oversettes, og en artikkel uten oversettelse er synlig som et tomt felt i en liste. Hull i lister blir tettet. Stille utelatelser blir det ikke.

#Produkter som ikke er én gjenstand

Grønne vegger og ferdige arrangementer bryter med antakelsen en vanlig katalog hviler på, nemlig at et produkt er én gjenstand med én pris og én lagerbeholdning. En vegg har en flate, settes sammen av moduler, og tilgjengeligheten følger av delene. Et arrangement i potte er et sett av flere planter og en beholder, solgt som en helhet og lagret hver for seg.

To veier finnes, og valget mellom dem er en arkitekturbeslutning. Den første behandler et slikt produkt som en egen oppføring med egen beskrivelse og egen beholdning, løsrevet fra komponentene. Den er enkel og holder så lenge settene er få, og den brister i det øyeblikket en komponent utgår, for settet ser fortsatt tilgjengelig ut. Den andre beskriver produktet som en sammensetning og regner ut tilgjengeligheten fra delene. Den er riktigere og dyrere, siden hver listevisning da må regne mer enn det oppføringen selv inneholder.

Grensen ble lagt der den som regel hører hjemme: det som kjøpes fra hyllen er en oppføring, og det som lages etter mål er en forespørsel med et datablad og en samtale. Å late som om en grønn vegg med oppgitt flate er et produkt med kjøpsknapp, ender i en ordre som ikke kan utføres uten en telefon. Da er det bedre å planlegge den telefonen inn i nettstedet enn å forklare den i etterkant.

#To lagre bak én produktside

Warszawa og Białystok betyr at den samme varen kan ligge to steder. I forbrukersalget spiller det liten rolle, for summen teller. I prosjektsalget gjør det det: førti stykk fordelt på to lokasjoner gir en annen monteringsdato enn førti stykk på ett sted.

Teknisk følger det at beholdningen bør føres per lokasjon selv om produktsiden viser en sum. Summen kan regnes ut fra delene når som helst, mens delene aldri kan hentes tilbake fra summen. Det er den samme regelen som tidligere avgjorde at parametere lagres i felt og ikke i brødtekst: data lagres så finkornet som det gir mening, og forenkles først ved visning.

I dette sortimentet kommer en detalj til. Planter fra to leveranser skiller seg synlig i grønnfarge, så en lobby trenger førti stykk fra samme parti og ikke førti stykk fra hvor som helst. Den opplysningen hører hjemme på siden, for ellers stilles spørsmålet i hver eneste forespørsel og svaret er likt hver gang.

#Filene hører ikke hjemme på applikasjonsserveren

Bildene bærer nesten hele vekten i denne katalogen, og det lar seg ikke redusere bort, siden det er bildet kjøperen bedømmer bladverk og innfatning etter. Spørsmålet er derfor ikke hvor mange bilder som skal være der, men hvor de skal ligge.

De ligger i S3 og leveres gjennom CDN, ikke fra filsystemet til applikasjonsserveren. Begrunnelsene er praktiske. Applikasjonsserveren skal sette sammen sider og ikke sende gigabyte med bilder, siden begge deler konkurrerer om de samme prosessene. Sikkerhetskopien vokser ikke lenger i takt med katalogen, så et testmiljø står oppe på minutter i stedet for en time. Og et serverbytte flytter ikke lenger en filhaug, fordi filene ikke er bundet til maskinen.

Kompromisset hører med i beskrivelsen. Utvidelser som forventer bilder rett på disken virker ikke lenger av seg selv, og generering av miniatyrstørrelser må planlegges bevisst. Den andre kostnaden er cache-invalidering: et utskiftet bilde på samme adresse når ikke fram til en nettleser som allerede har lagret det, så en ny versjon får et nytt filnavn. Uten den regelen retter redaksjonen et bilde, ser fortsatt det gamle, og mister tilliten til administrasjonen.

#Hva som er synlig etter lansering

Overvåkingen var en del av leveransen og ikke et tillegg solgt for seg, og den ser etter tre forskjellige ting. Først tilgjengelighet, altså det enkleste spørsmålet om nettstedet svarer. Deretter applikasjonsfeil, som i en nettbutikk sjelden legger hele stedet ned og som regel ødelegger én sti: en oppdatering kan forstyrre fraktsteget mens resten virker, og da melder ingen fra på en uke. Til slutt responstid på de visningene som faktisk koster, altså kategorilisten med aktive filtre og ikke forsiden.

Trafikken fordeler seg ujevnt gjennom året. Den stiger foran høytidene og i periodene der bedrifter pusser opp kontorer og lokaler, og enkeltdager gir et mangedobbelt av vanlig belastning. Å stille inn etter månedssnittet er derfor lite verdt; topptimen teller. Der avgjør framfor alt hvor mange forespørsler som når fram til applikasjonen, siden CDN tar bildene og objektcachen i Redis korter ned sidebyggingen.

Sikkerhet består av kjedelige, regelmessige handlinger: oppdatering av kjerne, tema og utvidelser, gjennomgang av logger, kontroll av tilganger og prøving av endringer på en kopi før de går i produksjon. Der ekte transaksjoner går gjennom et skjema, er en oppdatering kjørt rett i produksjon en driftsrisiko og ikke en spart time.

#Forespørsler som ikke ender i handlekurven

En del av etterspørselen stanser før kassen. En arkitekt trenger et antall trær i samme høyde til et prosjekt, en messebygger en grønn vegg med gitt flate og frist, et hotell planter som skal gjennom en brannteknisk kontroll. Slike saker avsluttes i en samtale, og nettstedets oppgave er en annen enn i forbrukersalget: å føre den som spør så langt at det første oppfølgingsspørsmålet ikke lenger trengs.

Teknisk betyr det at nettopp de opplysningene beslutningen hviler på må være strukturerte. Total høyde og pottediameter, fordi plassen er gitt. Brannhemmende utførelse som eget felt, fordi det i offentlige bygg er et vilkår og ikke en ekstrautrustning. UV-bestandighet, fordi en plante bak glass mister farge i løpet av en sesong. Å ha disse tre som filtre er ikke bekvemmelighet, det er forhåndsutvalget en selger ellers gjør i innboksen sin.

#Våre handlinger

På vår side lå gjennomføringen av butikken ut fra layouten kunden leverte: produktmodellen med parametriske felt, katalog- og produktvisninger, søk med filtrering, fillagring i S3 med levering gjennom CDN, cachelaget, forberedelse av katalogen for indeksering og overvåking etter lansering. Kravet som ordnet resten av avgjørelsene var at katalogen skal kunne vedlikeholdes uten utvikler, og at veien fra inngang til riktig produkt skal være kort.

#Sammendrag

Tre avgjørelser bestemte kvaliteten på denne leveransen, og ingen av dem gjaldt det grafiske laget. Produktparametere som felt i stedet for setninger gir filtrering og forhåndsutvalget som prosjektforespørsler trenger. Flyttingen av filene til S3 med levering over CDN tar bort arbeid applikasjonsserveren ikke burde gjøre, og holder sikkerhetskopiene små. Overvåking rettet mot de stiene som virkelig koster, korter ned tiden mellom at ett steg svikter og at noen oppdager det. Jeg har ingen målinger av effekten av dette arbeidet, så jeg oppgir ingen.

Til neste prosjekt følger det tekniske laget og arbeidsmåten med: WordPress med egen produktmodell, Redis, S3 med CDN, overvåking og testing av filtre og betaling på en produksjonskopi. Det som ikke følger med er attributtordboken til denne butikken og integrasjonene, for begge ble laget for et konkret sortiment og konkrete dataformater. Et nytt prosjekt starter med en omfangsanalyse, og tilbudet kommer etter den.