Na stronie widać tekst, zdjęcia, formularz czy kalendarz, ale żeby to wszystko działało, trzeba poukładać znacznie więcej rzeczy. Przy własnych projektach uczyłem się domen, poczty, serwerów, połączeń z innymi usługami i testów. Zebrałem te doświadczenia w jednym miejscu, bo każda z tych spraw przynajmniej raz zatrzymała mi pracę, choć z perspektywy odwiedzającego pozostawała niewidoczna.
Domena, czyli adres strony
Pierwszą domenę podpinałem jeszcze do Algebry i już wtedy wyszło, że kupienie adresu to dopiero początek. Adres musi prowadzić tam, gdzie stoi strona, poczta musi wiedzieć, dokąd iść, a usługi, z których strona korzysta, chcą dowodu, że domena naprawdę należy do mnie. Wszystko to ustawia się w czymś w rodzaju książki adresowej internetu, która mówi reszcie sieci, co gdzie się znajduje.
Dziś tę książkę adresową dla moich domen prowadzi Cloudflare. Nie da się tam jednak kupić adresu z końcówką .pl, więc kupuje się go u polskiego sprzedawcy domen, a potem przekazuje Cloudflare zarządzanie nim. W sierpniu przeniosłem Algebrę na krótszy adres, algebraispolka.pl, a stary ustawiłem tak, żeby każdy link sam prowadził do swojego odpowiednika pod nowym. Stara domena wygasa we wrześniu, dlatego przekierowania zrobiłem z miesięcznym wyprzedzeniem, żeby ani uczniowie, ani wyszukiwarka nie trafili na pustą stronę.
Poczta, która dochodzi
Maile z aplikacji wysyłałem na początku przez zwykłą skrzynkę Gmaila. Na małą skalę to działało, dopóki nie okazało się, że usługa, na której stała strona, takiej wysyłki po prostu nie przepuszcza, a Gmail potrafi podmienić nadawcę na własny adres. Dlatego w nowszych projektach maile wychodzą przez Resend, usługę do wysyłania poczty z aplikacji, z adresu w domenie projektu.
Żeby taka poczta nie lądowała w spamie, domena potrzebuje trzech wpisów we wspomnianej książce adresowej. Pierwszy mówi, kto może wysyłać maile w jej imieniu, drugi dokłada do każdej wiadomości podpis, a trzeci podpowiada skrzynkom odbiorców, co zrobić z mailem, który tych sprawdzeń nie przeszedł. Poczta przychodząca na adresy kontaktowe trafia przez Cloudflare do mojej zwykłej skrzynki, więc nie muszę utrzymywać własnego systemu pocztowego. Tam, gdzie liczy się czas, dostaję też powiadomienie na telefon i na WhatsAppa.
Własna maszyna w chmurze
Większość moich projektów działa w usługach, które same uruchamiają aplikację i nie wymagają, żebym czegokolwiek pilnował. Czasem potrzebowałem jednak zwykłego komputera w sieci, na którym mogę zainstalować, co chcę. Tak trafiłem do Oracle Cloud, gdzie w darmowym planie można dostać taką maszynę, wystarczającą do sporej części moich potrzeb.
Przez jakiś czas obrabiała ona filmy dla strony Duostrings i obsługiwała część Planera Operacyjnego. Własna maszyna to jednak zupełnie inna odpowiedzialność niż usługa, która robi wszystko sama, bo trzeba samemu instalować aktualizacje, pilnować, żeby po ponownym uruchomieniu wszystko wstało, i ustawić bramkę, przez którą programy są widoczne z zewnątrz. Przy prostszych projektach wygodniej więc mieć usługę, która zdejmuje to z głowy. W Duostrings pod koniec czerwca maszyna do filmów przestała być potrzebna, bo pliki trafiają dziś prosto do magazynu przez samą stronę.
Połączenia z usługami Google'a
Moje projekty łączyłem z usługami Google'a wiele razy i za każdym razem inaczej. W Algebrze przez kilka tygodni zimą bazą danych był arkusz Google, z którego aplikacja czytała dane i do którego je zapisywała, o czym piszę w osobnym wpisie. Działało, ale wolno, więc szybko zastąpiła go prawdziwa baza danych. Później doszło logowanie kontem Google, a w innych projektach połączenia z arkuszami i z danymi geograficznymi. Za każdym razem wyglądało to podobnie: najpierw projekt po stronie Google'a, klucze dostępu, uprawnienia i zgody, a dopiero potem pierwsza linijka kodu. Najwięcej czasu zajmowało zwykle to, czego w kodzie nie widać.
Makra, czyli nagrane klikanie
Zanim asystentowi AI dało się po prostu zlecić obsługę przeglądarki, powtarzalne klikanie automatyzowałem dodatkiem do przeglądarki o nazwie UI.Vision. Nagrywa on kliknięcia i wpisywany tekst, a potem odtwarza je jako makro. W pracy przydawał się tam, gdzie to samo trzeba było zrobić dziesiątki razy: dane z plików PDF przenosiłem do arkusza, z arkusza do pliku dla makra, a ono na tej podstawie wypełniało w przeglądarce kolejne formularze albo otwierało po kolei setki pozycji do przejrzenia.
Takie makro ma jedną wadę: jest kruche. Wystarczy, że przycisk na stronie przesunie się albo zmieni nazwę, a całe nagranie przestaje działać. Dlatego z czasem zastąpiłem makra programami napisanymi w narzędziu, o którym piszę niżej. Szukają one przycisku po tym, czym jest, a nie po tym, gdzie stoi.
Testy, które klikają za mnie
Playwright to narzędzie, które steruje prawdziwą przeglądarką bez udziału człowieka: otwiera strony, klika, wpisuje, robi zrzuty ekranu i sprawdza, czy wynik jest taki, jak trzeba. Używam go dziś niemal w każdym projekcie. W Algebrze od wiosny po każdym wydaniu nowej wersji sprawdza na działającej stronie najważniejsze ścieżki, w Duostrings wgrywanie plików i szybkość strony, przy śpiewniku robi zrzuty w rozmiarze iPada, pionowo i poziomo, a przy grze muzycznej otwiera dwie przeglądarki, które rozgrywają ze sobą cały pojedynek.
Na początku sierpnia doszedł jeszcze Sentry, program, który zbiera błędy z działającej już aplikacji. Testy mówią, czy coś działa przed wydaniem, a Sentry, co psuje się po nim. Przydał się od razu, bo pomógł wyjaśnić sprawę płatności, które nie dochodziły do końca. Wystarczyło poprawić jeden adres w ustawieniach bramki płatności i potwierdzenia wpłat zaczęły docierać.
Dwa lata nauki
Te dwa lata były dla mnie czasem bardzo intensywnej nauki: technologii, narzędzi AI, domen, poczty, maszyn w chmurze, ustawień i testów. Z zewnątrz widać z tego tylko strony i aplikacje, a przecież każda z nich stoi na kilku warstwach, które trzeba było najpierw zrozumieć, a potem ustawić tak, żeby działały bez mojego udziału. Dziś, zaczynając nowy projekt, jeszcze przed pierwszą linijką kodu wiem, gdzie będzie stał, skąd będzie wysyłał maile i jak sprawdzę, że działa.