Wysokiej jakości sztuczne rośliny - sztuczne-rosliny.pl

#sztuczne-rosliny.pl, sklep internetowy z wysokiej jakości sztucznymi roślinami

Zamówienia w tym sklepie mają dwa bardzo różne kształty. Jedno to pojedyncza monstera do mieszkania, wybrana wieczorem na telefonie. Drugie to czterdzieści oliwek tej samej wysokości do lobby hotelu, z terminem montażu i wymogiem niepalności. Ta sama karta produktu musi obsłużyć obie sytuacje, a to znaczy, że nie może być plakatem. Musi być dokumentem.

Firma zajmuje się importem i dystrybucją roślin sztucznych, działa też jako hurtownia i dostawca aranżacji zieleni dla biur, hoteli, restauracji, centrów handlowych i stoisk targowych, z montażem i doradztwem na miejscu. Siedziba jest w Warszawie, oddział w Białymstoku, a w ofercie stoją drzewa, trawy, kwiaty i donice, w tym warianty trudnozapalne i odporne na promieniowanie ultrafioletowe oraz ściany zielone (źródło: sztuczne-rosliny.pl).

Wdrożenie zajęło około sześciu tygodni. Warstwa techniczna to WordPress z własnym modelem produktu, Redis jako cache obiektowy, HTML5, CSS3 i SASS po stronie interfejsu, AJAX w wyszukiwaniu, przechowywanie plików w S3 z CDN przed nimi oraz monitoring po starcie. Układ i rozmieszczenie elementów dostarczył klient, a ja zbudowałem na nim szablony, model danych i integracje.

#Zdjęcie jest specyfikacją, nie ilustracją

W tej branży fotografia nie ozdabia karty produktu, tylko ją opisuje. Kupujący ocenia z niej odcień zieleni, fakturę liścia, sposób osadzenia w donicy i to, czy pień wygląda na materiał, czy na tworzywo. Dokładnie tam przebiega granica między rośliną, która w przestrzeni działa, a taką, którą widać z dwóch metrów. Dlatego galerie są rozbudowane, pliki duże, a ciężar strony leży prawie w całości po stronie obrazów.

Z tego wynika decyzja o miejscu przechowywania plików. Zdjęcia leżą w S3, a nie na dysku serwera aplikacji, i są serwowane przez CDN. Powodów jest kilka i żaden nie dotyczy mody. Serwer aplikacji ma składać strony, a nie wysyłać gigabajty obrazów, bo jedno przeszkadza drugiemu w tej samej puli procesów. Kopia zapasowa bazy przestaje puchnąć razem z katalogiem, więc odtworzenie środowiska testowego jest kwestią minut, a nie godziny. Migracja na inny serwer przestaje wymagać przenoszenia kilkudziesięciu gigabajtów, bo pliki nie są przywiązane do maszyny.

Kompromis też trzeba nazwać. Pliki poza systemem plików WordPressa oznaczają, że wtyczki operujące na obrazach wprost na dysku przestają działać w oczywisty sposób, a generowanie miniatur trzeba świadomie zaplanować. Drugi koszt to unieważnianie cache. Podmiana zdjęcia pod tym samym adresem nie dociera do przeglądarki, która ma je już zapisane, więc nowa wersja pliku dostaje nową nazwę. Bez tej zasady redakcja poprawia zdjęcie, widzi stare i traci zaufanie do panelu.

Na liście kategorii decyduje nie waga jednego obrazu, tylko suma. Widok z pięćdziesięcioma produktami pobiera pięćdziesiąt plików, więc miniatury są generowane w rozmiarze, w jakim faktycznie się wyświetlają, a nie skalowane w przeglądarce z pliku przygotowanego pod kartę produktu. To detal konfiguracji i jedna z niewielu zmian, które widać na telefonie w zwykłej sieci komórkowej.

#Redakcja katalogu, czyli praca, która dzieje się codziennie

Sklep z takim asortymentem nie jest projektem, który się kończy w dniu startu. Oferta zmienia się razem z dostawami, a osoba prowadząca katalog pracuje w panelu codziennie. Jeśli dodanie rośliny wymaga programisty, katalog przestaje odpowiadać rzeczywistości w ciągu jednego sezonu, niezależnie od tego, jak dobrze wygląda w dniu odbioru.

Model produktu jest zbudowany na własnych typach treści i polach niestandardowych. Wysokość, materiał, kolor, rodzaj donicy, producent oraz informacja o wersji trudnozapalnej i odpornej na UV są wartościami w bazie, a nie zdaniami w opisie. Dzięki temu redakcja wypełnia formularz, a nie pisze tekst, w którym trzeba pamiętać o kolejności informacji, a każdy wpis wygląda tak samo, bo wygląd jest zadaniem szablonu, nie osoby wprowadzającej dane.

Druga sprawa to wersje językowe. Sklep prowadzi ofertę również po angielsku, a to znaczy, że część danych jest wspólna, a część musi być osobna. Wysokość, średnica donicy i numer katalogowy są takie same w każdym języku i powielanie ich to proszenie się o rozjazd. Nazwa, opis i zastosowanie są tłumaczeniem i muszą mieć własne miejsce. Rozdzielenie tych dwóch grup pól przed startem jest pięcioma minutami pracy, a po starcie jest migracją całego katalogu.

Trzecia rzecz dotyczy porządku w kategoriach. Rośliny da się porządkować na kilka sposobów naraz: gatunkiem, wysokością, przeznaczeniem i stylem wnętrza. Kuszące jest zrobienie z każdego z nich osobnego drzewa kategorii, ale wtedy ten sam produkt wisi w czterech miejscach i redakcja pilnuje czterech list zamiast jednej. W praktyce jedna hierarchia jest podstawą nawigacji, a pozostałe wymiary są atrybutami, po których się filtruje. Ta decyzja wygląda na organizacyjną, a jest techniczna, bo przesądza o liczbie adresów, które sklep wystawia na zewnątrz.

#Zapytania projektowe obok koszyka

Część popytu nie kończy się w koszyku, tylko w zapytaniu. Architekt potrzebuje kilkudziesięciu sztuk w jednej wysokości, firma targowa ściany zielonej o zadanej powierzchni i terminie, hotel roślin, które przejdą odbiór przeciwpożarowy. Te sprawy kończą się rozmową, a strona ma w nich inne zadanie niż w sprzedaży detalicznej: doprowadzić pytającego tak daleko, żeby pierwsze pytanie zwrotne nie było już potrzebne.

Technicznie oznacza to, że dokładnie te parametry, według których zapadają decyzje projektowe, muszą być strukturalne. Wysokość całkowita i średnica donicy, bo miejsce jest ograniczone. Wersja trudnozapalna jako osobne pole, bo w budynkach użyteczności publicznej to warunek, a nie wyposażenie. Odporność na UV, bo roślina za szybą traci kolor w ciągu jednego sezonu. Filtr po tych trzech cechach to nie wygoda, tylko preselekcja, którą inaczej robi handlowiec w skrzynce pocztowej.

Drugi temat to dostępność w ilości. Dla klienta detalicznego produkt jest dostępny albo nie. Dla zamówienia projektowego liczy się, czy czterdzieści sztuk pochodzi z jednej dostawy, bo rośliny z dwóch partii różnią się odcieniem na tyle, że w jednym pomieszczeniu to widać. Ta informacja należy do strony, bo w przeciwnym razie pojawia się w każdym zapytaniu z osobna, a odpowiedź za każdym razem jest ta sama.

#Co widać po starcie

Monitoring jest tu częścią wdrożenia, a nie dodatkiem sprzedanym osobno, i pilnuje trzech różnych rzeczy. Pierwsza to dostępność, czyli najprostsze pytanie, czy strona odpowiada. Druga to błędy aplikacji, które w sklepie rzadko kładą całą witrynę, a zwykle psują jedną ścieżkę: aktualizacja wtyczki potrafi rozstroić krok wysyłki, a reszta sklepu działa i nikt niczego nie zgłasza przez tydzień. Trzecia to czas odpowiedzi na widokach, które naprawdę kosztują, czyli na liście kategorii z aktywnymi filtrami, a nie na stronie głównej.

Obciążenie jest sezonowe i to zmienia sens pomiaru. Zapotrzebowanie rośnie, kiedy firmy przygotowują lokale przed świętami albo po remoncie, więc historia z całego miesiąca uśrednia to, co najbardziej interesujące. Sensowny wykres pokazuje najgorszą godzinę doby, a nie średnią dobową, bo tylko w tej godzinie widać, czy serwis stoi na własnych nogach. Sama odpowiedź na nadmiar żądań jest zresztą prosta: obrazy nie docierają do aplikacji, bo obsługuje je CDN, a to, co zostaje, skraca cache obiektowy.

Utrzymanie po stronie bezpieczeństwa nie jest dziedziną pomysłów, tylko rytmu: aktualizacja rdzenia, motywu i wtyczek w ustalonym cyklu, przegląd logów, okresowa kontrola kont z dostępem do panelu oraz sprawdzenie każdej zmiany na kopii przed wypuszczeniem jej na produkcję. Ta ostatnia zasada bywa traktowana jako formalność, a jest jedyną, która chroni sklep przed sytuacją, w której poprawka wykonana w pięć minut zatrzymuje składanie zamówień na godzinę.

#Produkty, które nie są jedną sztuką

Ściana zielona i gotowa aranżacja łamią założenie, na którym opiera się typowy katalog, czyli że produkt to jeden przedmiot z jedną ceną i jednym stanem magazynowym. Ściana ma powierzchnię, jest składana z modułów, a jej dostępność wynika z dostępności elementów, z których powstaje. Kompozycja w donicy to zestaw kilku roślin i pojemnika, sprzedawany jako całość, ale magazynowany osobno.

Są dwa sposoby, żeby to obsłużyć, i wybór między nimi jest rozstrzygnięciem projektowym, a nie szczegółem. Pierwszy to potraktować taki produkt jako osobny wpis z własnym opisem i własnym zdjęciem, oderwany od stanów części składowych. Jest prosty i sprawdza się, dopóki zestawów jest kilka, a psuje się w momencie, w którym jeden z komponentów znika z oferty, bo zestaw nadal wygląda na dostępny. Drugi to opisać produkt jako złożenie i wyliczać dostępność z części. Jest poprawniejszy i droższy, bo każdy widok listy musi wtedy policzyć więcej, niż wynika z samego wpisu.

W tym sklepie granica poszła tam, gdzie zwykle idzie sensownie: to, co klient kupuje z półki, jest wpisem, a to, co powstaje pod wymiar, jest zapytaniem z kartą informacyjną i doborem na rozmowie. Udawanie, że ściana zielona o zadanej powierzchni jest produktem z przyciskiem kupuję, kończy się zamówieniem, którego nie da się zrealizować bez telefonu, więc lepiej ten telefon przewidzieć w projekcie strony niż tłumaczyć się z niego później.

#Dwa magazyny i jedna karta produktu

Firma ma siedzibę w Warszawie i oddział w Białymstoku, a to znaczy, że ten sam towar może leżeć w dwóch miejscach. Dla sklepu detalicznego bywa to obojętne, bo liczy się suma. Dla zamówienia projektowego nie jest, bo czterdzieści sztuk rozłożone po dwóch lokalizacjach to inna data montażu niż czterdzieści sztuk w jednym miejscu.

Techniczny wniosek jest taki, że stan magazynowy warto trzymać rozbity na lokalizacje nawet wtedy, gdy na karcie produktu pokazywana jest suma. Agregat da się policzyć z części w każdej chwili, a części z agregatu nie da się odzyskać nigdy. To jest ta sama zasada, która wcześniej zdecydowała o zapisywaniu parametrów w polach zamiast w opisie: dane trzyma się w najbardziej szczegółowej postaci, jaka ma sens, a upraszcza się dopiero przy wyświetlaniu.

#Nasze działania

Po naszej stronie było wdrożenie sklepu na podstawie układu dostarczonego przez klienta: model produktu z polami parametrycznymi, widoki katalogu i karty produktu, wyszukiwanie z filtrowaniem, obsługa plików w S3 z dostarczaniem przez CDN, warstwa cache, przygotowanie katalogu pod indeksowanie oraz monitoring po starcie. Celem, który organizował resztę decyzji, było utrzymanie katalogu bez udziału programisty i doprowadzenie kupującego do właściwego produktu w kilku ruchach.

O jakości tego wdrożenia zdecydowały trzy rozstrzygnięcia, a żadne z nich nie dotyczyło warstwy graficznej. Parametry produktu zapisane jako pola, a nie jako zdania, dały filtrowanie i preselekcję dla zapytań projektowych. Wyprowadzenie plików do S3 i oddanie ich przez CDN zdjęło z serwera aplikacji pracę, której nie powinien wykonywać, i odchudziło kopie zapasowe. Monitoring ustawiony na ścieżki, które naprawdę kosztują, skraca czas między awarią jednego kroku a jej wykryciem. Nie mam pomiarów efektu tych prac, którymi mógłbym się tutaj posłużyć, więc żadnych nie podaję.

Na kolejne wdrożenie przenosi się warstwa techniczna i sposób pracy: WordPress z własnym modelem produktu, Redis, S3 z CDN, monitoring i testowanie filtrów oraz płatności na kopii produkcji. Nie przenosi się słownik parametrów tego sklepu ani jego integracje, bo powstały pod konkretny asortyment i konkretne formaty danych. Kolejny projekt zaczyna się od analizy zakresu, a wycena idzie po niej.